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an extensive methodology for software conversion costing; 11 case 
studies of software conversion projects at federal agencies; and a 
27- item glossary. (ESR) 



******$**************** **************** ******************************** 

* Reproductions supplied by EDRS are the best that can be made * 

* from the original document. * 
*********************************************************************** 



ERLC 



U.S. Dtpartmtnt 
of Commtrc* 

Natibnal Bureau 
of Standards 



Computer Science 
and Technology 



o 

sD 

-3" 



NBS Special. Publication 500-105 

Guide to Software Conversion 
Management , 




U.S. DEPARTMENT OF EDUCATION 

NATIONAL INSTITUTE OF EDUCATION 

EDUCATIONAL RESOURCES'INFORMATION 
CENTER (ERIC) 
^jL^his docijmont has been reproduced as 
received" from the person or organization 
• originating it. 
Minor changes have been made to improve 
reproduction quality 



► Points of view or opinions stated in this docu- 
ment do not necessarily represent official NIE 
position or policy. 



NATIONAL, BUREAU OF STANDARDS 



The National Bureau of Standards 1 was established by an act ot Congress on March-3, 1901. 
The Bureau's overall goal is to strengthen and advance the Nation's science and technology 
arid facilitate their effective- application for public benefit. To. this end, the Bureau conducts 
research and provides: (l)*a basis for the Nation's physical measurement system, (2) scientific 
and technological services /or industry and government, (3) a technical basis lor equity in 
trade, and (4) technical services to promote public safety. The Bureau's technical work is per- 
formed by the National Measurement Laboratory, the National Engineering Laboratory, and 
the Institute for Computer Sciences and Technology, f 
, / 
THE NATIONAL MEASUREMENT LABORATORY provides the national" system x>\ 
physical and chertVical and materials measurement; coordinates the system with measurement 
systems of other nations and furnishes essential services leading to accurate and uniform 
physical and chemical measurement throughout the Nation's scientific community, industry, 
and commerce; conducts materials research leading to improved methods of measurement, 
standards, and data on the properties of materials needed by industry, commerce, educational 
institutions, and Government; provides advisory and research services to other Government 
agencies; develops, produces, and distributes Standard Reference Materials; and provides 
calibration services. The Laboratory consists of,the following centers: 

Absolute Physical Quantities 2 — Radiation Research — .Chemical Physics — 
Analytical Chemistry — Materials Science - 

THE NATIONAL ENGINEERING LABORATORY provides technology and technical ser- 
vices to the public and private sectors to address national needs and to solve natiohal 
problems; conducts research in engineering and applied science in support of these efforts; 
builds- and maintains competence in the necessary disciplines required to carry out this 
research and technical se/vice; develops engineering data and measurement capabilities; 
provides engineering measurement traceability services; develops test methods and proposes 
engineering standards and code changes; develops and proposes new engineering practices; 
and develops and improves mechanisms to transfer results of its research to the ultimate user. 
The Laboratory consists of the following centers: 



Applied Mathematics — Electronics arid Electrical Engineering 2 — Manufacturing 
Engineering - Building Technology — Fire Research — Chemical Engineering 2 % 

THE INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY conducts 
research and provides scientific and technical services to did Federaf agencies in'the selection, 
acquisition, application, and use of computer technology to improve effectiveness and 
economy in Government operations in accordance with Public Law 89-306 (40 U.S.C. 759). 
relevant Executive Orders, and other directives; carries out this mission by managing the 
Federal Information Processing Standards Program, developing Federal ADP standards 
guidelines, and managing Federal participation in ADP voluntary standardization activities; 
provides scientific and technological advisory services and assistance to Federal agencies; and 
provides the technical foundation for computer-related policies of the Federal Government. 
The Institute consists of the following -centers: 



Programming Science and Technology — Computer Systems Engineering. 

•Headquarters and Laboratories'at Gaithersburg. MD. unless otherwise noted; 
mailing address Washington. DC 20234. 

'Some divisions within the center are located at Boulder, CO 80303. 



Computer Science 
and Technology 

v-. ' ^ 

aa-l._l..Mlaaaaaaaaaaaaaaaaaaaaaa- 



NBS Special Publication 500-105 , 

Guide to Software Conversion 
Management - / 

> 

M. Skall, Editor 



Institute for Computer Sciences and Technology 
National Bureau of Standards 
Washington, DC 20234 



Prepared by: CRC Systems, Incorporated 
40'ZO Williamsburg Court > 
Fairfax, VA 22032 



i 



\ 



U.S. DEPARTMENT OF COMMERCE 

Malcolm Baldrlge, Secretary \ 

National Bureau o! Standards 

Ernest Ambler, Director ' 

Issued October 1983 s 



s 




Reports on ComputerJM|ence and Technology 



The National. Bureau of Standards h.as a special responsibility within the Federal 
Government for computer science and technology. -activities. The, programs of the 
NBS Institute for Computer Sciences and Technology are designed to provide ADP, 
standards, guidelines, and technical advisory services to improve the effectiveness 
of computer utilization in the Federal sector, and to perform appropriate research 
and development efforts as foundation for such' activities and .programs. This 
publication series will report these NBS efforts to the Federal computer community as 
well as to interested specialists in the academic and private sectors. Thqse wishing 
to receive notices of publications th this series should complete and rskffn the form 
at the end of {his publication. 



( 



Library of Congress Catalog Card Nurhber: 83:600589 



National Bureau of Standards Special Publication '500 : 1 05 
Natl. Bur. Stand. (U.S.), Spec. Publ. 500-105,220 pages (Oct.1983) 

COdEN: XNBSAV 



■ f 



.s. governmentVrinting office 

WASHINGTON: 1983 



For sale by the Superintendent fof Documents, U.S. Government Printing Office, Washington, DC 20402 

\ Price $6.50 

(Add 25 percent for other than U.S. mailing) 



9 

ERLC 



SECTION' 



1.1 
1.2 
1.3 
1.4 

1.5 

1.7 

1-8 
' 1.9 

1.10 
1.11 

2'.1 
^ 2.2 
. 2.3 ' 

2.4 



2.5 

2.6 
2.7 



TABLE OF CONTENTS. 
DESCRIPTION 



ABSTRACT 
INTRODUCTION 

i 

OVERVIEW 

GUIDE QUALIFICATIONS 
HISTORY OF SOFTWARE CONVERSION 



PAGE 



>■ 1 
2; 

, 2 
3 
5 



software conversion in the 

information system life cycle 7 ' 

project initiation phase ' 9 

conversion requirements phase 11 

conversion planning phase 11 

conversion preparation phase 12 

conversion phase 12 

post-conversion phase 12 

appendices 13 

•project Initiation "Phase 14 

reasons for conversion 14 

project initiation objective 16 

project initiation activities 16 

project Management appointment and 

project team establishment m 16 

information system user 

and top management interface 19 

20 



PROJECT REPORTING AND CONTROLS^ 
PRELIMINARY PLANNING 



•i • 21 



in i 



table of contents 

description 

accomplishing the feasibility 
study and cost analysis 

project Initiation*, 
management decisions 

economic considerations 

project initiation 
management checklist 

conversion requirements phase 

requirements phase objectives 

conversion requirements activities 

project team staffing 
and organization 

application systems and programs 
inventory extension and assessment 

data files inventory 
extension and assessment 

conversion tools / 
identification and selection 

workload estimation refinement 

" distributed and teleprocessing, 
requirements definition 

SYSTEMS SOFTWARE 
REQUIREMENTS DEFINITION 

PERSONNEL REQUIREMENTS DEFINITION 

SECURITY REQUIREMENTS DEFINITION 

CONVERSION FACILITIES - • 

REQUIREMENTS DEFINITION 

SOFTWARE CONVERSION 
STUDY PREPARATION 



1 



TABLE OF CONTENTS 
' DESCRIPTION - PAGE ' 

v — — — — ■ 

requirements phase . 

management decisions 50 

cost and economic considerations 51 

requirements management checklist 52 

conversion plann1n gvphase .54 

pl a n nin g ob je ctives 54 

decisions impacting planning 55 

.conversion plan nin g activities^ 56 

Organization of the 

project team for planning r 58 

conversion -staffing^lan 58 

planning for contractual 
assistance/automated conversion-tools 61 

planning for training ^ ,64 

planning the. soft ware conversion 
schedule and developing planning 
tracking mechanisms 'r 66 

software preparation planning 73 

functional user and 

executive involvement '76 

-hardware activities'^} 77 

planning for locating 

the conversion team 78 

planning for documentation 

of converted'programs 78 

contingency planning 78 

security/ planning 79 

telecommunications planning 80 

formal Conversion plan so 



TABLE OF CONTENTS 
DESCRIPTION PAGE ' 

PLANNING DECISIONS 82 

ECONOMIC CONSIDERATIONS 82 

PLANNING MANAGEMENT CHECKLIST 83 

CONVERSION PREPARATION PHASE 356 

OBJECTIVE 85 
DECISIONS IMPACTING 

SOFTWARE CONVERSION " 87 

CONVERSION PREPARATION ACTIVITIES 87 

BUDGET APPROVAL > 89 

DEVELOPMENT OF WORK PACKAGES 89 

ASSEMBLE CONVERSION TEAM 90 

TRAINING ' 90 

OBTAINING CONTRACTUAL ASSISTANCE 

AND AUTOMATED CONVERSION TOOLS 91 

LOCATINC CONVERSION v • 

TEAM/OBTAINING EQUIPMENT 93 

CONVERSION FACILITIES >'•' 93 

DEVELOPMENT OF TEST FILES AND DATA 93 

PROGRAM MODIFICATION AND 
INCORPORATION^ USER - 

ENHANCEMENTS INTO SOFTWARE 94 

DOCUMENTATION , l 95 

HARDWARE PROCUREMENT ~ 95 

USER AND TOP 

MANAGEMENT INVOLVEMENT 95 

TRACKING PROGRESS 96 

DEALING WITH UNFORESEEN PROBLEMS 96 



VI 



FRIC 



, TABLE OF CONTENTS 
SECTION DESCRIPTION PAGE 1 

5.18 CONVERSION PREPARATION 

MANAGEMENT DECISIONS 100 

1 

5.19 ECONOMIC CONSIDERATIONS 100 

5.20 CONVERSION PREPARATION 

MANAGEMENT CHECKLIST 4 101 

6 THE CONVERSION PHASE 103 

6.1 OBJECTIVE 103 

6.2 CONVERSION PHASE ACTIVITIES 103 

6.3 MANAGEMENT, ORGANIZATION 

AND STAFFING 105 

6.4 EXTERNAL INTERFACE AND COORDINATION 107 

6.5 TRAINING / 109 

6.6 SECURITY CONSIDERATIONS 109 

6.7 THE SOFTWARE CONVERSION 109 

6.8 ; UNIT AND SYSTEMS TESTING 111 

6.9 PARALLEL TESTING AND CROSSOVER 114 

6.10 DOCUMENTATION - 114 

6.11 CONVERSION MANAGEMENT DECISIONS 115 

6.12 . ECONOMIC, CONSIDERATIONS * 115 

6.13 CONVERSION PHASE 

~S MANAGEMENT CHECKLET 116 

7 THE POST-CONVERSION PHASE 118 

7.1 OBJECTIVES 118 



2 POST-CONVERSION ACTIVITIES 118 

"\ 

7.3 CONVERSION TERMINATION/TRANSITION 

ACTIVITIES • 121 



10 



SECTION 
7.4 
7.5 

7.6 

7.7 

7.8 

7.9 J 

APPENDIX A 
APPENDIX B 

APPENDIX C 
APPENDIX D 
APPENDIX E 



TABLE OF CONTENTS 
DESCRIPTION 
COST TRACKING 

POST-fCONVERSION ANAL^fSIS 
AND ASSESSMENT , 

PLANNING AND INITIATING ACTIONS 
TO IMPROVE FUTURE CONVERSIONS 

POST-CONVERSION 
MANAGEMENT DECISIONS . 

ECONOMIC CONSIDERATIONS 

POST-CONVERSION 
MANAGEMENT CHECKLIST • 

BIBLIOGRAPHY < 

CONVERSION DIRECTIVES, STANDARDS 
AND REFERENCES 

SOFTWARE CONVERSION COSTING ■ 

CASE STUDIES 1 

GJbeSSARY OF TERMS USED IN 
IN THIS GUIDE 



11 



Vlll 



LIST OF' FIGURES 

* 

FIGURE DESCRIPTION 

1-1 Software Conversion Organization 

1-2 Software Life Cycle * 

1-3 ' ' Software Life Cycle 

1-4 Software Conversion Life Cycle ' 

1- 5* Software Conversion Phase Relationships 

2- 1 Project Initiation Phase Activities 

2- 2 ■ Prepare and Finalize Feasibility Studv 

3- 1 Conversion Requirements Phase Activities 
.3-2 Sample Program Worksheet 

3-3 Complexity Table 

3- 4 _ Sample File Worksheet 

4- 1 Conversion Planning Phase Activities " 
4-2 Sample Matrix Management Planning 
4-^ Sample Reporting Hierarchy 

4-4 Sample Application System Schedule 

4-5 Sample Application Program Schedule 

4^6 Sample File Conversion Schedul| 

4-7 Sample Personnel Assignment Schedule 

4-8 Project Management Tracking Packages 

4-9 Sample Weekly Program Status Report 

4-10 ^ Sample Weekly Status Timeline 



LIST QF FIGURES 

it 

FIGURE % * " DESCRIPTION PAGE 



Sample Outline of Conversion Plan 81 

5- 1, Phase Interaction . 86 
5"2 Conversion Preparation Activities 88 

6- 1 Conversion Phase Activities 104 

r 6-2 Software Conversion Team Skills 106 

and Numbers Over Time 

6-3 Unit and Systems Testing s 112 

7 ~1 Rost-Conversion Activities * • 119 

C"l s Cost Development Process 149 

Software Conversion Cost Element Detail 152 

c ~3 Software Conversion Function Be tail 158 

. C-4 Relationship of Phases and 

Cost Elements to Conversion Functions 162 

C"5 Economic Considerations by Phase 173 




GUIDE TO 



SOFTWARE CONVERSION MANAGEMENT 
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ABSTRACT 



This guide was developed to help Federal ADP managers 
understand the entire process of software conversion and manage that 
process more effectively. Software conversions have life cycles with 
distinct phases. A better understanding of the coftversion process and its 
' associated costs, should help managers to planyand execute more 
software conversions more efficiently, effectiveljr^nd with minimum 
operations disruption to Federal agencies. Although extensive references 
were consulted in preparing this guide, the" most important sources were 
interviews conducted at fourteen Federal agencies that had completed or 
were involved in software conversion projects. 

Keywords: Conversion costs; conversion planning; project management; 
conversion requirements; conversion preparation; conversion execution; 
documentation. 



SECTION 1 
INTRODUCTION 



1.1 OVERVIEW 

Previous studies of Federal conversions conducted by the 
General Accounting Office and the National Bureau of Standards revealed 
that there were fnanag'ement-related problems in the planning and 
execution of software conversion (23, 42. 43). In preparing for this guide 
interviews were conducted at fourteen Federal agencies. Managers were 
consulted who were involved in planning, preparing for, executing, or 
assisting in software conversions. These interviews revealed that the 
management problems addressed by GAO and NBS persist, because: 

o The total software conversion process is not well 
^ understood, 

o This lack of understanding leads to inadequate planning, 
preparation and a failure to apply practical management 
procedures at the right time to control the conversion 
process, 

o Software conversion costs and resources are not totally 
understood, considered or applied. 

The goal of this guide is to provide information which can be 
used by Federal ADP system managers to resolve management problems 
and to accomplish all aspects $f a software conversion in a more 
expeditious and cost-effective manner. Specifically, this guide is to 
provide assistance in the following areas: 
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Understanding software conversion, 


0 


Planning, 


o 


Project control, 


0 


Scheduling, 


0 


Staffing, 


0 


Application of resources. 



There are many references which apply to software 
conversion. However, no reference treats the entire software conversion 
process from start to finish. In this regard, this guide is unique. It 
provides managers a perspective and description of software conversion, 
from project initiation through post conversion. It facilitates better 
understanding of the conversion process and thus, better management. It 
is not intended for this guide, however, to replace 
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other obligatory or useful directives and references. This guide serves as 
a supplement to other references and facilitates their application to 
specific agency conversions. 

Software conversions in the Federal government range from 
very large projects taking upwards of fiye years to complete to very small 
projects lasting a matter of months. The conversions, which involve 
both code compatible machines and non-code compatible machines, 
vary in complexity. Further, Federal agencies differ considerably 
in size, organization and function arid in their use of ADP. It is not 
feasible to develop a guide which covers every software conversion 
possibility. Consequently, this guide does not dictate a single method for 
accomplishing software conversion; rather it describes a broad range of 
procedures, techniques, considerations and activities, which if selectively 
implemented, will assist managers in minimizing the negative aspects of 
software conversion upon an agency's ADP organization, information 
systems and system users. It should provide managers the insight 
necessary to tailor conversion planning and execution to actual agency 
needs. 

Additionally, the guide stresses many of the problems common 
to conversion efforts. These include not only short term problems 
specific to a conversion- such as inadequacies in project management, but 
also longer term problems which have an impact on conversion and other 
software management considerations as welL An example of the latter is 
failure to use standardized languages. Use of non-standard languages, not 
only increases difficulty in conversion but also limits the ability to 
transport that software to another agency which might desire its use. 

1.2 GUIDE QUALIFICATIONS 

1.2.1 SOFTWARE CONVERSION-HARDWARE REPLACEMENT 

Most software conversions result from the need to replace 
hardware systems because of processing saturation or equipment 
obsolescence. While there are other reasons for software conversion (e.g M 
transfer of a mission from one agency to another with a concomitant 
transfer of information systems), this guide is oriented towards conversion 
stemming from hardware replacement. Further, this guide assumes a 
non-code compatible conversion since this conversion condition produces 
the most problems and thus the most management lessons. 

Users of this guide are cautioned that hardware replacement 
has only been addressed to support discussion of software conversion. 
From a total agency ADP standpoint there are many more hardware issues 
of interest to management. While this guide provides a limited discussion 
of some hardware replacement problems, a manager who is interested in 
both software conversion and hardware conversion must consider sources 
of information other than this guide. 
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1.2.2 



SOFTWARE CONVERSION LEVEL OF EFFORT 



This guide is oriented towards a medium- to large-scale effor^ 
converting non-data base management systems (DBMS), business 
applications. Since Federal system conversions range from very small to 
very large and include other types of softwaresuch as DBMS, scientific, 
modeling, and operating systems, managers may need to modify this guide 
to apply to specific agency requirements. H 

1.2.3 LEVELS OF MANAGEMENT 

There are essentially four levels of management involved or 
interested in software conversion. , . / 

o Ex te rna 1 M anage m en t - This management is at the 
appropriations or approval level, e.g., Office of 
Management and Budget 

o Top Management - Internal management at the 
department level exercising broad approval and policy, 
v and program roles. 

o Technical - Middle management involved with 
overall data processing, planning, and operations, e.g., 
manager of a data processing activity or ADP manager. 

o Technical Supervision/Staff - That management 
responsible for specific data processing operations, e.g., 
v the supervisor of systemsynalysts and programmers. 

This guide focuses on management activities at the technical 
management and technical supervision/staff levels. These are the levels 
where exceptional management skills must be applied to achieve 
successful conversions. 

1.2.4 AGENCY STRUCTURE 

This guide assumes a hypothetical agency structure (see 
Figure 1-1). . J 

i 

o Top managers are those whose day-to-day interests 
concern overall agency functions and who exercise broad 
approval and policy and program roles. Nevertheless 
their support and understanding of software conversion 
issues are important to the success of any conversion 
(18). 

V 

o Functional users are the users of agency information 
system (e.g., personnel, finance). They assist in software 
conversion, particularly in parallel testing. 



o The ADP manager is the manager of all agency data 
. processing activities - both hardware an^, software. 

o The hardware and operations manage* , is responsible for 
, day-to-day machine and communications operations, 

* o The software manager is responsible for day-to-day 

applications, programs development and maintenance as 
, well as systems programming. During software 
conversion this manager has in added, paramount 
interest in conversion activities. In the post-conversion 
phase this manager also ensures that post conversion 
plans and activities are accomplished. Thus, this 
manager has a strong coordination function with the 
conversion project manager. 

o * The conversion project manager is assigned full-time 
during the software conversion process. After 
conversion is completed the project manager returns to 
normal duties associated with day-to-day 
responsibilities. On a large conversion project there may 
I be a full-time project management team. 

Many conversion problems result because of lack of 
understanding of conversion nfanagement issues on the 
part of upper level management It is to a software 
conversion manager's advantage to achieve as much 
software conversion project visibility as possible in order 
to effectively compete for management attention and 
Resources. In this regard the software conversion project 
manager has been placed directly under the ADP 
^^manager in order to illustrate tfite need for high level 
visibility. # v * * 

U HBTORY OF SOFTWARE CONVERSION $ ^ ^ 

Software conversion is generally viewed in the Federal ADP 
community as a traumatic 'and disruptive experience, to be avoided as 
loi^f as possible, endured when necessary, and forgotten as quickly as 
possible. However, software conversions are common in the Federal 
government. Hardware systems are replaced on an average of every 
seven to eight years (23). The information systems processed on this 
hardware system commonly have a much longer life span, particularly 
major applications supporting such functions as finance and accounting, 
personnel, and payroll. This means that conversion is a historical step 
rather than an aberration in an information system's life cycle. If it is 
viewed as a recurring, historical event, management practices can be 
applied to improve conversion as they are applied to improve other 
software processes in the life cycle. 



Functional 
User 



r 



Hardware Q 

Operations 

Manager 



Operations 
Staff 



External 
Resources 



Top 
Management 



Functional 
tfser 



Functional 
User 




Interface — — 
I 



. JL-*-^ 

! Conversion ■ 
I Project • 
I Manager * 

I 
I 
I 

f- -*- - - -I 

Conversion ' 
< Project V« 
• Team I 
L J 



1 



Software 
Manager 



Serves as Software 

Conversion 

Manager 





Applications 
Programming 


Applications 
'rogramming 


Systems 
Programming 


t 

\ 






f 



SOFTWARE CONVERSION ORGANIZATION 

V 

Figure 1-1 



1.4 SOFTWARE CONVERSION IN THE INFORMATION SYSTEM 

LDPECYCLE 

The traditional and well understood model of an information 
system's life cycle is depicted in FIPS PUB 38, * Guidelines^ for 
Documentation of Computer Programs and Automated Data, Systems and 
FIPS PUB 64, Guidelines -for "Documentation of Computer Programs and 
Automated Data Systems for the Initiation Phase (22, 25) (see figure 1-2), 
If conversion is acknowledgqd as part of the information system's life 
cycle, it could be placed in the software life cycle's operations phase (see 
Figure 1-3). 

Examination of the activities or processes which constitute 
software conversion reveals that there is a conversion life cycle imbedded 
in the overall information system's life cycle. This software conversion 
life cycle, itself, has distinct phases (s^e Figure 1-4). 

* o Project Initiation - The phaseNjn which management 

acknowledges software conversion is a distinct possibilty 
in the near term. Managers determine if conversion 
must be accomplished or if feasible alternatives exist 
(e.g., improving the existing hardware system capacity,* 
shifting workload to anothelr-computer, or improving the 
efficiency of existing software). 

o Conversion Requirements - The phase in which, after 
determining that conversion must be accomplished, 
studies and analyses are conducted to identify all agency 
conversion requirements and cost estimates in detaiL 

o Conversion Planning - The phase in which conversion 
details are translated into detailed conversion plans. 



o Conversion Preparation - During this phase all 
preparation activities leading to actual software 
conversion, itself, are conducted. 

o Conversion Process - The phase during which software is 
actually converted. 

o Post Conversion - Dtiring this phase the conversion 
project, per se, ends. Long-range planning is conducted 
for the next conversion. Management also has the 
opportunity to improve the next conversion by 
implementing practices and measures which are 
conducive to efficient conversion. The later stages of 
the post conversion phase eventually lead to ;4he next 
project initiation phase. 
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The phased approach of viewing software conversion provides 
the structure fop this guide. However, in an actual conversion many of 
the activities associated with each phase proceed in parallel (see 
Figure 1-5). .For example, this guide treats planning lis a phase although 
planning is a continuous process. Likewise, while conversion requirements 
are being developed, preparation activities can be ongoing. Similarly, 
some software conversion may commence before preparations are 
finished. The reader or user of this document is asked to keep in mind 
that the sequential, or phased approach to this guide presentation must be 
tempered with the understanding that different activities also proceed in 
parallel. 

1.5 PROJECT INITIATION PHASE 

This is the phase in which management determines that 
software conversion . is a distinct possibility in the near term. A 
conversion project manager is appointed and a small project team is 
assembled. A feasibility study is accomplished to determine if 
alternatives to conversion exist. If the most feasible alternative is 
procurement of new hardware, preliminary planning commences. In 
addition to the feasibility study other studies may be performed (e.g., to 
satisfy tha requirements' of Office of Management and Budget (OMB) 
Circular AV6, Policies for Acquiring Commercial or Industrial Products 
and Services for Government Use and OMB Circular A -109, Major 
Systems Acquisition ). 

There are two management pitfalls to avoid in this phase: 
failure to appoint a full lime project manager with the authority and 
responsibility to complete the initial planning and manage the conversion 
effort from start to finish, and failure to start studies and planning early. 
Many conversion projects are delayed while inadequate plans are 
strengthened or experience slippages later in conversion due to planning 
oversights. 

Key top management decisions are appointment of a project 
manager, approval of feasibility and other studies as required (e.g., 
OMB Circulars A-?6 and A-109). 
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1.6 CONVERSION REQUIREMENTS PHASE A 

After approval of the feasibility study, the project manager 
. and project team develop the details necessary to completely plan the 
conversion* Alternatives to many conversion activities (e.g., choosing 
specific automated conversion tools) (ye decided on a cost-effective 
basis. ■ 

The project manager also develops a software conversion study 
in this phase which is used to support an agency ogociuiement request 
(APR) submitted to the General Services Administration (GSA) for 
hardware procurement. This study must be well constructed and carefully 
costed. it is particularly important to examine software conversion costs 
from a standpoint of converting to code compatible versus non-code 
compatible hardware. Generally, cost avoidances can be high in a 
code-compatible conversion, but this approach must be fully justified and 
supported. 

Jh addition to the software conversion study, other studies 
initiated # in accordance with OMb Circulars A-76 and A-109 may be 
ongoing and require input. 

It is important to address security and privacy requirements in 
this phase. These tend to be overlooked from a systems standpoint but 
are extremely important. Incorporating security and privacy features into 
software during conversion is relatively straightforward if considered and 
planned well in advance. ^ 

The major management issue in this phase is maintaining 
continuity of -the project manager and project team to allow them to 
develop the software conversion study and the details necessary for 
thorough planning. 

^ The key management decision is approval of the software 
conversion study. 

1.7 CONVERSION PLANNING PHASE 

As the detailed requirements arje developed, they are 
converted into conversion plans to support staffing, acquiring conversion 
contractor support, locating the conversion project team, acquiring 
necessary conversion facilities such as terminals, training, and 
accomplishing the actual conversion! Tracking mechanisms are also 
developed to keep management apprised of conversion progress. If a fully 
competitive hardware selection is in progress, planning must remain 
flexible until the target hardware is known. The conversion project 
manager maintains close coordination with agency personnel involved ih 
hardware acquisition in order to gain early insight of planning impacts 
stemming from acquisition decisions. jf* 

The key management decision in the conversion planning phase 
is approval of all conversion plans necessary to complete the conve^on. 
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IA CONVERSION PREPARATION PHASE ^ 

After conversion plans are developed, preparations are made 
for concentrated conversion of software. Preparations should be 
complete prior to conversion to preclude interruptions and wasted effort , 
Major preparation activities include assembling and „ training the 
conversion team, developing or obtaining conversion tools, installing 
equipment, obtaining conversion, facilities, developing test data and 
contracting fpr conversion support Tracking of conversion preparation 
plans ensures that schedules are met. 

v A 4 major management concern in the conv^sion preparation ^ 

phase is dealing with unforeseen problems^nch as unanticipated personnel ^£ 

losses and outside impacts such as budget cuts. Plans must remain ^ r 
flexible to accommodate these problems. 

^ The key management decision *in this phase is approval to j 
proceed with the conversion. ' 

1.9 CONVERSION PHASE 

During this phase software is converted. ^Jnit, s^tem and ^ 
parallel testing is conducted and operational systems are accepted by the 
information system users. 

The critical management issues are dealing with unforeseen 
problems to keep the conversion on track, monitoring contractor 
performance for compliance with Statements of Work and ensuring that 
established agency software standards are met and documentation is 
produced. 

The conversion phase ends when the last converted system is 
accepted by the functional user. A key management decision in this phase 
deals with accepting software* which may not have completed parallel 
testing (e.g., it may not be practical to parallel test year-end reporting). 
Considerable risk is removed if the agency has developed and maintained ° 
good test data, and unit and systems tests have been successf uL 

1.10 POST CONVERSION PHASE 

The first activities of the post-conversion phase involve 
disbanding the conversion project team and reorganizing the agency 
software operations into a normal, day-to-day environment. The project 
manager should conduct a post-conversion study and assess and record the 
entire conversion experience. Completion of activities to settle the staff 
in a normal software environment and the post-conversion analysis and 
assessment complete the conversion project. This post-conversion 
analysis and assessment has much utility in that it provides a historical 
reference of lessons learned, that may be applied in future conversions. * It 
also facilitates planning for the next conversion. This planning should 
begin immediately and should continue until the next conversion. 
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In addition to planning, agency software standards should be 
^enforced during the post conversion phase* Use of these standards will 
make the next conversion easier* Software security and privacy 
requirements, applied in a routine systematic fashion, will reduce the 
chance for oversight in a crisis conversion environment. / 

The critical management issues in* post conversion are 
completing the post conversion analysis and assessment, developing and 
maintaining conversion planning, and ensuring that software is developed 
and maintained to high technical standards* 

The key management decision in the post conversion phase is 
approving the post-^conversion plan. This terminates the conversion 
projept. * ^ .->'-. .. * ' ; V 

1.11 APPENDICES 

The* remainder ; of this guide follows the phases of the 
conversion life cycle presented above* Appendices to the guide include: 

BIBLIOGRAPHY 

' •/" ' ■ ' * 

Appendix A is the bibliography which was used in developing 

this guide* 

, , % ' '• ' • : * ■ ■ j " 

CONVERSION DIRECTIVES STANDARDS AND REFERENCES ■ ' . 

. ' * , ' ■ ■' ' v " 

Appendix B contains a list of directives and references that 
are applicable to software conversion* They are recommended to be part 
of any software conversion manager's library. ; • ' • , 

SOFTWARE CONVERSION COSTIN G ' 

I'll* J ' * ■ 

■ * ' a ■ * ' ' 

Appendix C contains a feosting methodology that managers can 
use to develop software- conversion cost estimates. It can be used in the 
' feasibility Study during the project initiation phase, the software 
conversion study to support the, t age noy procurement request, agency 
budgets, and to support any other cost requirements, . '../ '/», 

CASE STUDIES : : 

Appendix D contains software case studies that fl were 
developed from actual , agency experiences* They provide additional 

insight into software conversion's management issues. 

* * *• • • ■■, 

GLOSSARY 

Appendix E contains a glossary of terms used in this guide. 
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SECTION 2 



PROJECT INITIATION PHASE 



A point is reached in every information system's life cycle 
where conversion is considered in detail. The causes of conversion vary 
but are usually related to a real or perceived need to replace hardware. 
Eventually managers realize that software conversions^ no longer an 
event to be faced at some undetermined time in the distaiuNfuture, but a 
condition that is likely to occur and that requires initial b\it definitive 
consideration and planning. 

*" Prior to any extensive commitment of resources to support a 
full scale software conversion, a feasibility study is required by General 
Services Administration 41 CFR Part 1-4 , to firmly establish the need for 
a conversion effort. There may be viable alternatives to a conversion, 
such as keeping the present computer system running f for longerperiods of 
time (e.g., 3rd shift, weekends]^ reducing the workload by identifying and 
cutting nonessential processing, or distributing some of the workload to 
other computers. ^ 

In addition to providing decisive information on whether or not 
a conversion is necessary, preliminary planning provides management 
early insight on the magnitude, direction, resource requirements, and cost 
of the software conversion project. 

The time associated with project initiation activities, 
especially the planning, the estimating and statistical development, and 
conduct of the feasibility study should not be underestimated. Two to 
three person years of effort over six months could be required for a 
medium to large scale conversion. 

A positive attitude toward conversion should be developed in 
the software staff. Rather than viewing conversion as a disruptive 
process, conversion can be approached as professionally challenging, an 
opportunity to broaden professional skills; and to exercise initiative in a 
dynamic environment. Conversion, also offers an opportunity to upgrade 
the status of agency software to high technical standards. For example, 
old inefficient programs can be rewritten in standard languages using 
modern software engineering techniques. Documentation can be updated 
and made current. Unnecessary or outdated code can be, eliminated. 

14 REASONS FOR CONVERSION 

There are many reasons for software conversion. Each reason 
has different effects on agency software conversion processes ahd 
management involvetnenU r %. 



Hardware Processing Limits : Computer systems* 
saturation is the normal cause of software conversion. 
Hardware systems are commonly installed and 
continually upgraded to accommodate agency 
information systems as they are designed, implemented 
and enhanced. Eventually the point is reached where the 
hardware capacity for expansion no longer exists, 
information systems no longer are responsive to 
functional user needs, and little or no hardware 
resources are available for new application program 
development In unusual cases, primarily due to poor 
planning, hardware systems upon installation, are 
expanded to capacity in a matter of months. Commonly, 
however, hardware systems last approximately eight 
years before capacity limitations cfluse replacement. In 
the normal case, software managers should be able to 
anticipate conversion well in advance through analysis of 
trends and have ample time to tal^e all actions necessary 
to initiate conversion in an orderly fashion. 

Change in Missions and Functions : Federal agencies 
operate in a dynamic environment. Missions and 
functions can change as a result of new Federal laws and 
programs, and |s a result of agency consolidations and 
reorganizations. As established agencies gain additional 
missions and functions, their information requirements 
increase. These increased information requirements 
result in new demands for information systems which 
ultimately lead to hardware saturation. However, in the 
ca^e of hardware saturation caused by mission and 
function changes, conversion can be precipitated in a 
much more dramatic and shorter time frame than as a 
result of saturation due to normal systems growth. Thus, 
when mission and functions change, software managers 
usually have less time to initiate software conversion- 
projects. 

Operational Requirements : Retaining existing 
application system software may no longer be 
operationally viable. For example, vendor software may 
no longer be supported by the vendor. The existing 
software, without vendor maintenance support, may not 
be useful for new systems development and existing 
system enhancements. Rather than retain obsolete, 
unsupported software for some systems and introduce 
new software for new systems, with attendent 
requirements for increased and different training and 
documentation, agencies may convert all software; to a 
viable langyajje. Another example of conversion cSii^d 
by operational requirements has to do with old software 
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running in an emulation mode. Long-term emulation 
processing is generally inefficient for software that is 
frequently used* Managers may decide from a cost 
effective 9 as well as operational standpoint, to convert 
software running in an emulation mode. 

o Technology : Some Federal computer systems do not 
become saturated and are useful for many years. 
Eventually, however, their age or lack of technological 
sophistication dictate their replacement. Vendors or 
manufacturers eventually discontinue maintenance and 
other support to old hardware. In other cases, even 
though support is still available, operating costs 
associated with operations 1 staff, power, and air 
conditioning may be unacceptable. Modern hardware and 
software may support the same functional applications 
7 ' at considerably reduced operational cost. 

2.2 PROJECT INITIATION OBJECTIVE 

The objective of the project initiation phase is to conduct the 
preliminary planning and studies to determine whether a conversion should 
be undertaken. 

2.3 < PROJECT INITIATION ACTIVITIES 

■ f " 

A * ' 

The following activities occur during the project initiation 
ghase (see Figure 2-1): 

o Project manager appointment and project team 
establishment, 

o Information system user and top management interface, 
o Project reporting and control, ■ 
o Preliminary planning and estimating, 
o Accomplishing a feasability study and cost analysis, 
o Management decisions. 

PROJECT MANAGEMENT APPOINTMENT AND PROJECT 
' TEAM ESTABLISHMENT 

Of prime importance to a successful conversion is the 
appointment of a project manager with the requisite technical/ managerial 
background and the tenure and authority to manage the conversion 
project. Concurrently, a project team should be formed with the skills 
and experience necessary to accomplish the studies and analyses 
associated with the project initiation phase/ 
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The establishment of the project manager and project team • 
should include provisions for adequate logistical and administrative 
support and a sufficient operational budget. 

To be effective, there should be a separation between previous^ 
responsibilities and the conversion effort The project team, as a unit, 
should work uTs separate physical location. This location will serve as 
the focal point for the 'conversion. Distractions and interruptions wiU 
then be minimized, allowing the team to concentrate-on the conversion 
activities. » 

The appointment of the project manager and project team 
usually signifies the beginnfhg of software conver^pn cost expenditures. 
At this point direct costs can be identified to a particular project. Also, 
the assignment of a project manager is accompanied by accountability for 
project cost as part of the management responsibilities. 

2.4.1 PROJECT MANAGER APPOINTMENTS 

A full time project manager should be selected and appointed 
who will have experience and tenure to manage software conversion from 
project initiation to project completion. While this may appear seir 
evident, a significant number of Federal conversion projects have 
experienced difficulties because: 

o Conversion project management duties were assumed as 
additional responsibilities by fully committed software 
, staff members. 

o Project management was not exercised continuously 
through the different conversion phases. This lack of 
continuity disrupted and impeded conversion. 

The qualifications to be considered in selecting a project 
manager should include: 

o Planning ability, 

o Ability to organize and manage resources, 

o Project management and software conversion experience 
- Six to ten years of experience is recommended, 

o Ability to deal effectively with people, particularly 
personnel in agency elements external to ADP, such as 
the functional users of information systems, 

o Ability to react to problems and redirect efforts to 
resolve issues before they get out of hand. 
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While conversions should have only one project manager, it is 
conceivable that very large conversions might have a full-time project 
management team appointed for the duration of the project 

The project manager should be formally appointed and 
chartered in writing. The appointment should be approved by top agency 
officials. This provides project visibility and acknowledgement that the 
project manager has the authority to receive support and assistance from 
other organizational elements within the agency. 

2.4.2 PROJECT TEAM ESTABLISHMENT 

. The composition of the project team for this phase will depend 
upon several variables, which include project complexity, timeframe, 
budgetary and personnel constraints. 

Since project initiation activities are planning oriented, the 
project team should include one or more systems analyst(s), with three 
years minimum analytical and planning experience preferred. Team 
members must be familiar with the current ADP environment and 
applications, and be able to collect and evaluate workload statistics. 
Preference should go to selecting those personnel with previous 
conversion experience. Although the team during this phase may be very 
small, additional members can be added or reassigned as needs arise. 
Many managers use their most experienced personnel to assist in project 
initiation activities and continue to employ them in other subsequent, 
conversion activities. 

2.5 INFORMATION SYSTEM USER AND TOP MANAGEMENT 

INTERFACE 

Software conversion can be a lengthy and complex process 
dealing with an important agency asset — its information base. Software 
conversion alters this data base. Problem-ridden conversions can result in 
considerable harm to an agency and its operations. Conversely, efficient 
conversions can improve the information processing posture of an agency. 
Therefore, it is extremely important that the functional users of 
automated information systems and top agency executives understand the 
issues of software conversion and support the conversion effort. 
Experience has shown, however, that full functional user* and top 
management understanding and support are frequently not achieved . 

To overcome this, at project initiation, the project manager 
can employ a variety of techniques to develop and maintain user's and 
management's interest and involvement in the conversion effort. These 
include: 
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Briefings . Scheduled briefings are recommended to keep 
users and top agency executives apprised of project 
initiation activities. These briefings need not be formal. 
Short presentations as part of 3taff meeting agendas can 
be quite effective, especially since these meetings 
provide an opportunity to inform many managers and 
executives at one time of the conversion project status. 
• Such briefings are of particular importance to top 
management During the project initiation phase, 
agency executives will decide on conversion as a result 
of a feasibility study developed by the project manager 
and the project team. Regular briefings reduce the 
chance of surfacing surprises in the feasibility study, a 
point appreciated by management Study issues cfin be 
y 'raised well in advance for executive level attenti6n. 
Once scheduled briefings are established, they should be 
continued throughout the conversion effort until the 
project is complete. 

o Memoranda . Informal memoranda with general 
information of ongoing and planned activities might be 
employed. 

o Management Stuff Involvement . If it is difficult to 
directly inform top level managers of progress, it may be 
possible to inform or involve subordinate members of 
his/her staff who have immediate access and are charged 
with keeping top level managers informed of significant 
issues, or potential problem areas. 

o Articles in Af*P™ Newsletters . Frequent but short 
articles can keep top managers and users informed of the 
software conversion project. 

2.6 PROJECT REPORTING AND CONTROLS 

Effective reporting and controls must be established and 
adhered to during a software conversion. Without some mechanism for 
accounting for work in progress, work completed, and work to be started, 
the project manager will have great difficulty in project tracking and 
monitoring. 

2.6.1 REPORTING " 

At project initiation, reporting procedures can either be 
separate from, or merged with, other on-going, related actions (e.gM 
hardware replacement). These procedures should provide reports required 
by the project manager as well as higher levels of management Ihe 
initial framework for internal and external reporting should be formulated 
for the entire conversion effort 
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2.6.2 ^PROJECT HISTORY 

A project history should also be started during the project 
initiation phase. Thereafter it should be maintained by the project 
manager throughout the entire software conversion effort. The history 
should reflect significant project actions, events, costs, problems and 
means of problem resolution. It should also contain thoughts and 
observations of how subsequent project activities or future conversions 
can be improved. This history can be recorded in a journal or log or be 
contained in a project reference file. Ultimately the history log, if 
maintained, will be an invaluable reference in developing conversion plans 
and a post conversion analysis and assessment. 

2.6.3 PLANNING AIDS 

Project planning aids exist and include PERT, GANTT, and 
Work Breakdown Structures (WBS). Project planning aids selected for use 
are largely a matter of individual preference on the part of a project 
manager. However, at a minimum it is recommended that some visual, 
time dependent, planning aid such as bar charts be used. Although bar 
charts do not depict a critical path, they identify concurrent activities to 
alert the project manager of resource constraining areas that require 
special attention. They also visually portray starting and ending points of 
project activities and important milestones. 

2.7 PRELIMINARY PLANNING 

Adequate ADP project planning is one of the most critical 
factors of a successful software conversion. Federal procurement 
regulations require a feasibility study to be accomplished before any 
conversion to determine if other alternatives can resolve an agencies* 
information processing problems. 

Additionally, other related studies are often required in the 
same approximate time frame as the feasibility study. Software 
conversion results in a change to agency operations. OMB Circular A-76, 
Policies f or Acquiring Commercial or Industrial Products and Services for 
Government Use , requires examination of ADP operations at a time of 
significant change to determine if operations can be effectively turned 
over to a contractor. Also, an agency may consider hardware 
replacement and software conversion to fall under the provisions of OMB 
Circular A-109, Maior Systems Acquisition The project manager must 
have the planning and statistical base to accomplish the feasibility study 
or provide input into these other related conversion studies, as required. 

Unfortunately, software conversion preliminary planning is 
frequently postponed to a point where it has an adverse effect on 
conversion schedules, or js conducted inadequately and without sufficient 
detail, ultimately leading to project slippage. To overcome this 
management issue and to provide a firm foundation for the feasibility 
study and other related studies for which input might be required, early 
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preliminary plans should be developed to provide managers insight into the 
probable magnitude of the conversion project, gross resource 
requirements' and the probable length of time conversion will take, lhis 
can be accomplished by: 

i 

o Current procurement and acquisition regulations and 
policy review, 

o Current ADP hardware and system software inventory, 

o Preliminary systems and applications program inventory, 

o Data file inventory, 

o Preliminary workload estimation, 

o Levels of effort and resource estimation, 

o Preconversion/conversion cost methodology 

development. 

These activities accomplished by the project team during 
project initiation will provide a statistical and planning base fdr all 
subsequent conversion phases and activities. 

2 7i CURRENT PROCUREMENT AND ACQUISITION 

REGULATIONS AND POLICY REVIEW . 

Along with agency policy regulations, there are many 
pertinent Federal procurement regulations and directives promulgated by 
GSA, OMB and Congress, as weU as standards and guidelines promulgated 
by the National Bureau of Standards, that pertain to software conversion. 
The project manager and the project team should review this pertment 
documentation. Of particular importance are the following three areas 
addressed by these documents: 

o Hardware/software planning and acquisition, 
o Software conversion, 

o Timesharing and remote computing services. «r 

Appendix B to this guide contains the mostj important 
references that will assist in policy and regulation review. 

2.7.2 CURRENT ADP HARDWARE AND S YSTEM SOFTWARE 

INVENTORY 

The purpose of this" activity is to document all currently 
existing ADP equipment and system software in order to establish the 
current environment, and identify any potential vendor's unique problems 
if converting the application programs to noncompatible, target hardware 
is necessary. 
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Hardware Inventory 



A hardware inventory is necessary to understand the 
environment in which the software operates. Also, costs associated with 
hardware influence software feasibility studies. The project manager or 
the project team will be furnished the hardware inventory by the 
hardware staff. If not, the project team will have to establish it The 
hardware inventory and equipment configuration should describe and 
display all ADPE components and peripherals, located either on-site or at 
remote locations. At a minimum, this inventory should identify each 
component by: 1 

o ( Component name"", 
o Modelnumber, 
o Name of manufacturer, 
o Location. 

Although primarily focusing on computer center equipment, 
such as CPU, disk components, tape drives, printers, card reader/punch, 
and consoles, the inventory should also include such items as RJE stations, 
graphics equipment, data entry equipment, and other user-oriented 
hardware. Memory and storage capacity should also be identified. 
Additionally, an inventory of all commmunications equipment and network 
configurations should be acquired if data communications are employed. 

2.7.2.2 System Software Inventory 

The system's software inventory must encompass not only the 
operating system, languages, compilers, link editors, spooling and 
teleprocessing software, but also identify and describe utilities, software 
and hardware monitoring packages. The software inventory should include 
at a minimum: 

o Name of software or language, 

o Product number, 

o Manufacturer, 

o Version, 

o ' Release/level number, 

o Version/release date, 

o Date installed, 

o Local modifications, 

o Documentation available, location, and condition, » 

o System software lease, purchase or cost information. 

Care must be taken to document special conditions such as 
user exits and local modifications, where present. 
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The software inventory will be relatively straightforward if 
current system software documentation has been maintained. Where 
little or no documentation exists, the problem is magnified, but the 
inventory can and must be accomplished. To develop communications 
between the project team and the system programming staff, and to 
develop familiarity with systems software, it is recommended that one or 
two system programmmers temporarily augment the project team and 
provide systems software data. 

2.7.3 PRELIMINARY SYSTEMS AND APPLICATION PROGRAMS 

INVENTORY 

A preliminary inventory of application programs and systems 
currently in use serves a number of purposes: 

o This inventory is required to estimate the magnitude of 
the conversion. 

o It serves as a starting point in identifying those programs 
and applications that should be converted, if a 
conversion is approved. A more comprehensive and 
indepth inventory is undertaken once the conversion 
requirement phase starts. 

o Should a conversion not be justified as a result of a 
feasibility study, the inventory wfil secve as baseline 
documentation by the ADP staf^ durihg^any future 
conversion studies. 

The application program inventory is facilitated if one or more 
of the team members are familiar with the applications. Additional and 
supplemental information can be obtained from user groups. 

The inventory should include at least the following 
information: - y - 

o Name of system and brief description, 

o Numbers and programs within the system; lines of code 
per program and language; complexity of programming, 

"'' ' •••••• , 

o Interfaces with other systems, ,j 

v o Data bases accessed by the system. w 

' While extreme levels of apptications software detail are not 
required for ^project initiation activities, as much additional detail as 
possible should be developed, resources permitting. This will save time 
later, during the software conversion study conducted during the 
conversion requirements phase, when more extensive details are needed. 

Cognizant functional users should review and Verify the 
inventory and identify any applications that may have been missed- 

V 



2.7.4 DATA FILE INVENTORY 

The project team should identify and document data files that 
are generated and processed by each program, and files that ore shared by 
multiple programs and systems. This inventory contributes to the 
determination of the scale and complexity of the current software 
environment. The inventory is accomplished by one or more members of 
the project team through review of current program/system 
documentation, developed from workload statistical data and, where 
necessary, interviewing the appropriate users (39). 

The inventory should include at least the following 

File name, j 
Accessing system(s) name(s), 

Medium (i.e. tape, disk, cards, etc.), \ 

Data organization (e.g. sequential, random, . indexed, 
etc.), i f 

Code (e.g. BCD, EBCDIC; ASCII, etc.), 

Estimated size. : ^ t : ^ 

2.7.5 PRELIMINARY WORKLOAD ESTIMATION / 

1 j ,. . : 

Summary statistics are then developed to reflect the basic 
total system workload (e.g., percent CPU busy, mean turnaround, number 
of jobs processed, etc.) and a profile established of future workload 
requirements* Sihce tim£ is relatively limited during this phase, resource 
estimates should be based primarily on available or easily derived data. 
Most workload data is usually available from system operating statistics 
(e.g. * IBM System maintenance Facility, f SMF") ari4 accounting, billing 
and history data. The accumulation and summarization of detailed, 
resource workloads from hardware/software monitors is usually too time 
consuming at this points in conversion planning. However, some 
consideration should begin regarding methods to develop a more extensive 
assessment and collection of workload data which is required in the 
conversion requirements phase. >r\ 

2.7.6 LEVELS OF EFFORT AND RESOURCE ESTIMATION | * 

Personnel requirements are identified for each conversion 
activity and levels of effort are estimated for the entire software 
conversion project. While there are many methods for estimating 
resources, a common software conversion management method is 
judgement; based upon experience. The intent of- -this guide is not to 



information: 
o 
o 

! 

o 
o 

o 
o 



develop or recommend a particular estimating technique or. methodology, 
but rather to identify various techniques or methodologies that will lead 
to reliable estimates. Appendix C describes and. discusses in detail two 
popular* estimation techniques, which include th* tf avy's PMCS mode! and 
the Federal Conversion Support Center's Hybrid Model (45). These should 
be assessed first before any other models are considered. 

2.7.7 DEVELOPING PRECONVERSIOtt/CONVERSION COST 

METHODOLOGY , \ 

A software conversion cost methodology .'is described in detail 
in Appendix C. A me thodolo^ should be adopted: or developed during 
project initiation to provide a consistent basis fo^ -cost decisions 
throughput ,the project as well as for the feasibility study required during 
this phase, this cost methodology will be refined during the project as 
more detail is developed and more accurate cost estimates . c^an be 
prepared. The cost methodology must be used to track project 6Mts, : In 
this manner^he software conversion cost methodology can «^i0t-j>roject 
managemenTOy: 

o : Providing the ability to audit cost estimates, - 

o Identifying the major cost related efforts, v i 

o Providing a consistent cost information •; base for 
recording and projecting software conversion costs. 

2.8 ACCOMPLB0ING THE FEASIBILITY STUDY AND COST 

V> ANALYSE ■ | j{ ' 

the purpose of the preliminary' feasibility anc( cost 

analysis is to determine if there aire>alterhatives to software conversion 
and provide top management with adequate decision-making information. 
The study will be developed by the project manager and project team. If 
study input|is readily available, it swuld take approximately two months 
to complete This study, to be effective, must address: 

jo, The objectives, assumptions, constraints, and background 
; ! i of the current environment, * f'r 

o% 1 The background and status of^a^^fent system(s), 

o ^Projected or anticip&ted^fture requirements, v 

'^^^tm- * ntification of alternative approaches, 

or V* 'A summary of findings and recommendation(s) along with 
supporting costs/benefits/risks analysis. 
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' . ^:^iril!ess there are agency standards, it is suggested tftat I^IPS 
PUB 64^;u^ed as a guideline in completing the, feasibility 
analysis (22)1 The follow ing discussion istfe^^^ 

Pigtirfe ;^2-2 shows the relationship of the various .activities of the 
feasibility study which are: ;,;V 

6 Define Objectives, Scope, and Background - ~ 

This is the first step in a feasibility, study and is to 
-;V V define the objectives and scope of effort • 



o '■'"< Identify and Define the Current System 

The second step is to define the existing environment, 
organization, constraints, prior if ies, and -technical arid 
operational (workload) considerations dn Whichr this study 
is based. 

a Identify Alternatives 

ffi'y*? This 48 * e ke y stage where creative and intuitive 

I « thinking are employed. Viable alternatives and 1 solutions 

are identified and described. 

Besides the status quo, possible alternatives might 
include increasing the hours of computer system 
operation, reducing non-essential or non-productive 
work, distributive * processing, or conversion to larger 
hardware. 

o Assess Technical Operational Feasibility 

v'Vv ■■■■ t * : :;":V- * 

The technical and operational feasibility (i.e., satisfying 
*\ user requirements) of each alternative is assessed to 

. determine if they are suitable technologically and 
' operationally. 



o Estimate Costs of Alternatives 



All relevant costs (i.e., fecurring, and* non^riteurring and 
present value) of each alternative ritust be estimated. 
Cost estimates developed using the software conversion 
costing methodology should be based on the full cost of 
each alternative, and defined in sufficient detail to allow 
cost comparisons of individual elements of cost among 
alternatives. '■■ 
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Figure 2-2 
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Define and Describe Benefits 

Identify and define any quantifiable and non-quantifiable 
benefits or their estilrna ted values for each alternative. 
Do not overlook the intangible benefits. While these 
may be more difficult to estimate or assign values, in 
many cases they may carry more weight in the final 
analysis and decision-making* s These costs are 
reflected in each alternative, including the status quo 
alternative. Care must be taken to avoid r double 
counting of costs or benefits. 

Compare the Alternatives 

Compare the feasibility, of each alternative in terms of 
desirability ' and advantages/disadvantages. The 
comparison is based upon the technical, cost and 
operational factors identified above. 

Analyze Sensitivity' and Risk 

A useful tool in feasibility studies, is sensitivity analysis 
which is a method for determining the impact of changes 
in assumptions on the total 'cost of the alternatives. 
Sensitivity analysis should address the range of values 
for assumptions such asr workload, inflation factors, 
salaries, number of programs, complexity and conversion 
productivity. In this manner the least cost alternatives 
can be identified for any given range of assumption 
values and used with risk analysis to determine the 
preferred alternative. 

Recommendation and Implementation^Plan 

At this point, based upon the various cost/benefit and 
sensitivity analysis results, a recommendation or 
summary of findings is prepared, along with a proposed 
schedule for implementation. 

Finalize Feasibility Study 

When prepared objectively and with adequate 
information, the feasibility study will provide 
^management with the necessary data to make a decision 
as to the proposed recommendation. 
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tJ) PROJECT INITIATION MANAGEMENT DECBIONS 



At the conclusion of the feasibility study and cost analysis, the ADP 
manager presents study results to top management for decisions. If there 
is no feasible alternative to resolve the agency data processing problem 
other than software conversion, management will likely be faced with 
another large issue: hardware replacement* 

Once the software conversion decision is made, additional 
management decisions are required to support: 

o Software conversion resources, * 
o An extended conversion schedule, 
o Authority to begin the conversion requirements phase, 
o Project funding. 

It is recommended that the project manager present a decision 
briefi^j to top management and cover all decision requirements and 
recommendations as 'an entire package. This provides for efficient 
transition to subsequent software conversion phases. 

If software conversion is not selected as a feasible alternative, 
project personnnel revert to normal operational roles. Care should be 
taken to preserve the results of all project initiation phase, statistical 
data and study results since this will prove useful in any future conversion 
planning. ^ .+ 

2.10 ECONOMIC CONSIDERATIONS 

During the project initiation phase, personnel will be the 
largest cost component. Included in this cost could be significant 
expenses required for establishing the project team including new hire or 
relocation expenses, initial project training courses, and office set-up 
expenses. 

The software conversion cost methodology described in 
Appendix C should be initiated during this phase. A cost structure should 
be developed that represents the characteristics of the environment being 
costed and contain a level of detail that is sufficient to provide cost 
information for management use in the succeeding phases. The cost 
estimates developed during this phase will be based on summary levels of 
cost detail and may be provided through the use of software conversion 
cost estimation models, two of which are described in Appendix C. 

2.11 PROJECT INITIATION MANAGEMENT CHECKLBT 

o Appointment of full time project manager 
o Charter approved by top management 
o Ongoing project costs tracked 
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Project team established 

Top management and information system user interfaces 
established * 

Interface with hardware acquisition project members 
established 

Project reporting and project controls established 

■» 

Regular reporting in progress 
History log established 
Planning aids selected and used 

Impact of Related Studies Determined 

A-76 ' 
A-109 
Other 

Applicable acquisition and procurement, policy 
regulations and directives that affect software 
conversion identified and reviewed 

Hardware inventory conducted 

System software inventory conducted 

Data files inventoried 

Preliminary workloads estimated 

Conversion resources (personnel) estimated 

Cost methodology developed 

Project costs tracked 

Feasibility study and cost analysis conducted 

Management decision to proceed/not proceed with 
conversion 

Reorient efforts to proceed to next conversion 
phase 

Plan for and pursue efforts to accomplish other 
alternatives) 




^SECTION 3 



CONVERSION REQUIREMENTS PHASE 

The conversion requirements phase results in detailed 
identification and assessment of the scope, requirements, and 
complexities of the conversion effort. This phase is the transition 
between "what" is td be done (project initiation) and "how" it is to be 
accomplished (conversion planning). 

Once the decision to convert has been made, the conversion 
project team must identify all of the details necessary to plan and 
execute the conversion. This requires an analysis of the current 
environment to include identifying feasible alternatives to various 
conversion processes and activities. Management decisions can then be 
made to choose the most cost effective method of accomplishing the 
conversion activities. In addition to the planning details, during the 
requirements phase a software conversion study is required to determine 
if the users needs are met at the lowest overall cost (13). 

During the conversion requirements phase, the hardware 
procurement activities are interrelated and dependent on software 
conversion activities. For example, workload analysis ,is used %o 
determine the magnitude of the software conversion project. Workload, 
analysis also serves to help size the target hardware., needs^ * Most 
ijfnpdrtantly, the* software conversion fifcidy,. with, its. suppwting^cQSt 
; analyses, can identify procurement o^jti^R which differ ^considerably in 
cost ; and time to implement. ' The software r cohversioii- study should 
address conversion to cctie-compktible as well as noTOod^^ompatible 
hardware and the respective- costs and operational impacts carefully 
developed. Code-compatiMje conversions are usually much less costly and 
disruptive to agency operations. While approval of code-compatible 
conversions cannot be guaranteed due to Federal competetive 
procurement policies, the likelihood is improved if code-compatible 
conversion hardware procurement requests are supported by reliable and 
thorough cost analyses. 

3.1 REQUIREMENTS PHASE OBJECTIVES 

S 

Thq primary objective of this phase is to provide the 
information necessary to accomplish detailed conversion planning. An 
additional objective of this phase is accomplishment of a software 
conversion study which, in turn, supports preparation and submission of an 
Agency Procurement Request (APR) to the General Services 
Administration. 
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3.2 CONVERSION REQUIREMENTS ACTIVITI16 



The following conversion requests phase activities (shown in 
Figure ,3-1) must be conducted: 

o Project team staffing and organization, 

o Application systems and programs inventory extension 
and assessment, 

o Data file inventory extension and assessment, 

o Conversion tool identification and selection, 

o Workload estimation and refinement, 

o Distributed and teleprocessing requirements definition, 

o Systems software requirements definition, 

o Personnel requirements definition, 

o Security requirements definition, 

q Conversion facilities requirements definition, 

o Software conversion study preparation. 



3.3 PROJECT TEAM STAFFING AND ORGANIZATION 

3.3.1 PROJECT TEAM STAFFING 

The full-time project manager appointed during project 
initiation will continue to manage the conversion project during the 
requirements phase. The project team requires systems analysis skills 
and planning experience to develop requirements; the same skill base 
needed for project initiation. Since requirements definition and 
development of the software conversion study are analogous to activities 
in project initiation, the same team members should be adequate except 
for very large conversions. As a guideline however the following table is 
offered to aid in team staffing: 

Lines of Code 

To be Converted Team Size 

Less than 100 K 1-2 
100Kto 500K 2-3 
over 500 K 4-5 
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TEAM STAFFING & ORGANIZATION 

APPLICATION SYSTEMS INVENTORY 

DATA FILE INVENTORY 

CONVERSION TOOL SELECTION 

WORKLOAD ESTIMATION 

TELEPROCESSING REQUIREMENTS DEFINITION 

SYSTEMS SOFTWARE REQUIREMENTS DEFINITION 

PERSONNEL REQUIREMENTS DEFINITION : 

SECURITY REQUIREMENTS J^I NIT-ION 

FACILITY REQUIREMENTS flpiNITION 

SOFTWARE CONVERSION sfuf^ PREPARATION 



MANAGEMENT DECISION^ ',' T J 




conversion Requirements phase activities 



Figure 3-1 
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These figures ate derived, in part, from an Army estimate (39) 
and from case studies described in Appendix D, 

During the requirements phase the project team might be 
augmented by consultants, by guidance provided by the Institute for 
Computer Sciences and Technology (ICST), or by support from ttn&4?ederal 
Conversion Support Center* to assist in developing special r^quiret^ents 
such as security and teleprocessing or to accomplish ^uie software 
conversion study^ 

3.3.2 TURNOVER CONSIDERATIONS 

A key issue that management should anticipate, and plan for, 
is personnel turnover. The longer the project, the higher* the turnover 
rate. According to Tripp and Wahi (34), multi-year projects should plan for 
up to 25% turnover in staff per year. The implications /of this apply to 
lengthy requirements phases as well as entire conversion projects. 
Managers must be prepared to replace project team personnel and possibly 
project managers. ' * 

Problems in turnover may be reduced by team organization 
and assignment of duties. Primary responsibilities for conversion 
requirements can be assigned to individual team members. Other team 
members should be assigned secondary or back-up responsibilities. If one 
member leaves unexpectedly, the corporate project memory is not lost. 

Regjilarly conducted project discussions and reviews to keep 
all team members apprised of project status also contribute significantly 
to reducing the effect of project team personnel losses. 

3.4 APPLICATION SYSTEMS AND PROGRAMS INVENTORY 

EXTENSION 

♦ 

The purpose of this activity is to extend the application 
system and project inventory conducted during the project initiation phase. 
The details of the systems and programs in terms of complexity and 
construction are added to the inventory. 

This inventory will also identify specific systems and programs 
to be converted or dropped. The inventory will permit the project team 
to group and assess the agency- application software inventory from 
various perspectives. For example, the inventory can be considered from 
a standpoint of complexity, applicable conversion technique (e.g., 
automated tool, line-for-line coding, etc.), or language. Estimating of 

♦ 

Federal Conversion Support Center 
Software Development Office 
General Services Administration 
Two Skyline Place, Suite 1100 
Falls Church, Virginia 22041 
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levels of effort and identification of the best techniques to accomplish 
conversion are considerably aided by this inventory. Additionally, the 
project team will develop insight into many potential conversion problems 
and means to accomplish problem resolution. 

% Catalog .worksheets printed on large paper will assist the 
project team in inventorying and assessing application software. For very 
large conversions it is recommended that this worksheet be automated. 
Automation will assist the project team in easily analyzing the software 
inventory from various aggregate perspectives (e.g. language, lines of 
code, environment, or complexity). ^The. following information 
corresponds to a suggested worksheet (Figure 3-2) developed from Federal 
sources (39, 47). It should be modified according to specific agency needs. 

o PROGRAM ID : Specify a unique identifier for each 
program. 

o SOURCE LANGUAGE & VERSION ; Specify the pro- 
gramming language and version in which the current- 
program is written. 

o LINES OF CODE ; Enter ^e number of lines of code in 
the program. Indicate number of vendor extensions, if 
known. 

o MODULES AND EXTERNAL CALLS ; Specify the 
number of segments, calls to external subroutines, and v 
macros which are copied. 

o COMMUNICATION INTERFACES ; If the program inter- 
faces with communication drivers or special telecom- 
munication interfaces, indicate interface name and 
function, e.g., 3270 protocol/ sore en format 

o SOURCE PROCESSING ENVIRONMENT ; Specify the 
mode of processing such jas batch, remote job entry 
(RJE), interactive, or real-time for the source program. 

o FILES ; Specify the name and number of input, output aAd 
„. t input/output files processed by this program. Temporary 

files should not be included. 

o DOCUMENTATION ; Indicate the*level of documentation 
available for this program using the following codes; 
0 = None available; 1 = Insufficient . for conversion; 
2 = Satisfactory. 

o COMPLEXITY ; Specify the code that best reflects the 
level of program complexity. Refer to Figure -3. 

o TARGET LANGUAGE AND VERSION ; Specify expected 
language and version if target hardware is known. 
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COMPLEXITY TABLE 
Figure 3-3 



o TARGET" PROCESSING ENVIRONMENT : . Indicate 
whether theifiirget program processing environment will 
be batchy gemote job entry (RJE), interactive, or real- 
• ":' time. ^-l- s " t * 

• q COMMENTS : Enter any comments or information 'such 
as justification, priqiary user contact, regulatory author- 
ization, etc! If one or more automated tool(s) is 
applicable, enter name of "package; ; if . known. ». . 

.-..»., 

o CONVERSION gTATUS : Indicate the action to be taken 
for this program. C = Convert; P = Purged 

R = Redevelop. 

Other statistics which should t?e summarized for the entire 
conversion effort include: 

v. o Tptal number of programs by application systenj, 

' o The total number of lines of job stream language by 
application system, m 

% l o The number of job streams by application system, 

' v ^tir • '' -/IMajor .sy^eiQS^appUcations^by complexity, e.g., payroll, 
.? financial, personnel. ; 

3.5 DATA FILES INVENTORY EXTENSION AND ASSESSMENT - 

■ ■ , ( . 

Although this activity should haye been completed in project 
initiation, it is of .sufficient importance "to conduct a review (and 
refinement where necessary) prior to use in the software conversion 
study. * - 

In particular this activity should Concentrate on a reexam- 
ination and assessment of the data files in terms of determinipg if they 
can be converted as is; converted with minor changes, or require ma jot^ 
conversion due to architectural incompatibilities. - One of the > major 
technical management considerations in assessing file , conversion 
requirement is knowing and understanding the differences in data 
conventions (e g., XS3, ASCII, EBCDIC, BCD). Other items which must be 
addressed as file /requirements definitions include the collating. sequences 
qf the different^character sets arid the internal. character representation 
such as packed decimal, hexadecimal, or octaL The Jimp lications with 
respect to sorting, file maintenance, and their effect" on report listings 
are well known. , P 

File inventory information may plso be used to determine the 
priority or order of programs to be converted within a system and, to a 
greater or lesser extent, the order of systems defending upon file 
interrelationships^ an<3 in terdependencies between programs and ajpp li- 
gation systems. r : . \ *. ,v . ■ . 



Using the sample file worksheet (39., 47), (shown in Figure 3-4), 
the following infQrmation should be included in^sjnventc>ry:' 

■ o FILE ID : Specify a unique identifier for ea<?h file, 

o .FILE MEDIUM : » Indicate the storage medium, e.g., 
, 9->t£ack tape, removable disk, high speed drum. . 

o CODE TYPE : Selfect the appropriate code to indicate 
the code data is currently stored in:^ 



1 = ASCII 5 = Binary 

2 = EBCDIC 6 = Packed-decimal } 

3 *= .BCD * • 7 = Floating-point j 

4 - XS3 8 = Bit level 

9 = Other * , 

o NUMBER OF VOLUMES : Indicate If more thin one Upe 
reel or disk pack is-tfeijuired for this file. 

0 ACCESS METHOD ; Identify the appropriate file either 
sequential, direct access, or index sequential, 
organization which applies. If jione of these file 
organization techniques are applicable, specify the type 
of organization used. 

o RECORD FORMAT : Specify whether Vfi record format 
is "FIXED," "VARIABLE," or "OTHERi"?* It "OTHER," 
describe under 'COMMENTS. 

: \o RECORD SIZE : Specify the size (in characters) for each 
. file (use one line for each record type). Enter the 
• ; - number ofcrecdrds for each record format in the file. 
• ^r' ;> * 

o BLOCK SIZE : Specify/ the size (in characters) for length 
of the record block size. If file is Unblocked, enter 
• record size. 0 

.I* 

o SECURITY/PRIVACY : Ihdia^te whether special proce- 
dures will be iicteessary to protect the contents of the 
file^or to limit read/write access to the file or parts of 
. the file, indicate whether, 11 R" - Read or "W" - Write 
\ restrictions apply to the file! J 

o COMMENTS : (optional)/ . $71 ter any comments or addi- 
tional information about the file. Use this cplumn to 
further describe RECORD. 'FORM AT (if necessary) or 
applicable automated tools, if known. 

o CONVERSION STATUS : Indicate the action to be taKen 
for this file. C = Convert; P 0 = Purge, R s= Redevelop. 
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Figure 3-4 
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The file inventory data should then be summarized by access 
method with the following information provided for eaclwnethod: 

o File medium, e.g., disk, tape or card, 

o Total number of files, 

o Total number of characters, 

o Percentage of the total number of files which have data 
stored by code type, 

o Percentage of the total number of files which have fixed 
and variable length records,* 

o Percentage of the total number of files which require 
privacy or security protection. 

As with the applications and programs inventory, automation 
of the file inventory for very large conversions will help summarizing and 
analyzing file conversion parameters as they affect conversion 
requirements. 

3.6 CONVERSION TOOU5 IDENTIFICATION AND SELECTION 

Once the application systems program and file inventories 
have been completed and associated with an appropriate conversion 
technique, review of suitable and available automated to.ols should begin. 
Most agencies have some resident conversion tools. However, the 
screening should be expanded beyond this base. A reference of particular 
usefulness is the Federal Conversion Support Center Conversion 
Products/Aids Survey (46). 

3.6.1 TYPES OF TOOLS 

For the purpose of this guide, three basic types of automated 
tools are addressed: 

/ 

o Translators 

Translation is the process of automatically converting 
computer programs from one language to another or 
from one hardware configuration to another. It is rare 
that 100% translation is achieved, and inevitably manual 
final adjustment is required. 
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o 



Emulators 



It may not be practical to convert a program if a total 
redesign was planned immediately following a conversion 
or conversely, convert a program that will be terminated 
in the not top distant future. Operating the old 
programs using an emulator feature or package to 
represent the source machine on the target machine may 
offer a feasible alternative. However, other factors 
such as possibly degraded performance need to be taken 
into consideration before a decision is made to emulate. 



o Conversion Aids 

This category encompasses all other types of automated 
tools. These include file converters, test data 
generators, source program directories, optimization 
routines, standardization auditors, operating system 
fc converters, operation control stream language 
conversion, flow charting aids and benchmark 
generators. 

3.6.2 SELECTION AND OPTIMIZATION 

Feasibility study techniques should be used to select tools. 
For example, manipulation of program and file inventories will reveal 
areas where tools may be feasibly used. Alternative tools can be 
compared with — manual methods and costed to determine the most 
effective approach! 

Each tool has its inherent advantages and disadvantages 
depending upon the circumstances and environment involved. Moreover, 
it should be recognized that selection and implementation of any of these 
tools is but a part of the conversion effort. Use of these tools can 
enhance the actual program and file conversion effort, but they will not 
produce completely automated conversion. Some form of additional 
manual effort is required for efficient program and file operation on the 
source system. The need for this manual effort, and related costs, have 
to be considered when analyzing use of automated tools. Unless other 
estimates are known, estimate 20% manual effort — 80% automated tooL 

* Case study research associated with this guide uncovered one 
automated conversion where the target system consumed 20 hours of run 
time compared to tttree hotfrs execution time oh the source system. This 
is an extreme example but it illustrates that subjective human judgement 
of conversion results and manual refinement of application programs 
converted with automated tools are necessary tx*? optimize anc^ine-tune 
converted software. V 
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3.6.3 



CONVERSION TOOL EVALUATION FACTORS 



Candidate conversion tools should be weighed against the 
following considerations: 

o Availability 

Establish whether the tool is a well established "off-the- 
shelf" package or a new but untested one; determine 
whether it should be leased or purchased; determine how 
soon it can be delivered. 

o Documentation 

Determine if the package is fully documented; if 
documentation includes updates and revisions. 

o Support 

Ascertain if the vendor will stand behind the product; 
determine the history of the vendor and the package; 
judge whether the in-house staff can handle the package. 

o Operating Efficiencies and Costs 

Compare the tool to other similar tools in terms of 
purchase or lease cost, maintenance fees and support 
avaHSkility, hardware resources required, operator 
training required, and the availability and cost of such 
training. In terms of performance determine how the 
converted program(s) compare to the source program. 
Identify past users to verify this performance, and 
determine if the vendor would adhere to such perfor- 
mance claims in a contract. 

o Agency Nleeds 

Any particular considerations that apply to an agency. 
For example, will agency hardware handle the tools 
being considered. 

The Federal Conversion Support Center or contractors can 
assist in selection of automated tooKs) should resources, time, or 
experience preclude an in-house effort. 
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3.7 WORKLOAD ESTIMATION REFINEMENT 



The aggregate workload analysis conducted during project 
initiation should be further refined. This will require an in-depth analysis 
of not only production workloads but expected systems 1 enhancements and 
new systems 1 developments that will place a demand on the target 
hardware. 

The associated hardware capabilities, operating systems, and 
communication requirements complete this analysis. Factoring in 
historical "workload and projected user's requirements, future workload 
requirements can be extrapolated and summarized. This workload profile 
can 'then be analyzed as a complete, integrated entity. The profile 
picture will depict the operational environment that must be accom- 
modate*^ by the tergjet system. 

3.7.1 workiBad PARAMETERS 

~The : most coftrmon information (40) used to determine 
workload a?e?iten\iz£d beloW. t Utilizing hardware/software monitors (e.g., 
PLAN/4, TSOMO^ :t(S^iliVt<^':^taihing thie raw workload data. 

o JOBS PROCESSED - Number of batch jobs started. 

o TRANSACTIONS PROCESSED - Number of on-line 
transactions processed. 

o CPU TIME - Number of hours of total program 
CPU time (both batch and on-line). 

o DISK EXCP - I/O executions for all direct access 
devices, in thousands. 

o TAPE EXCP - I/O executions for all magnetic tape 
devices, in thousands. 

o LOCAL PRINT - Number of lines spooled for local print, 
in thousands. 

o REMOTE PRINT - Number of lines spooled for remote 
print, in thousands. 

o CONNECT TIME - Connect hours for terminals and RJE. 

o TAPE MOUNTS - Number of tape mounts, in thousands. 

After investigating the make-up of the jobs, transactions and 
connect times (if any), an analysis can be made of the effect of this 
workload on the system. Equipment resource utilization is a measure of 
work units needed to process the current workload on the source system. 
The main descriptive data elements for measuring resources used are CPU 
time, jobs pro^ssed, disk EXCEPS top EXCPS, and print volume. An 
additional element describing percent CPU busy time should also be 
included since it is a key indicator of maximum resource utilization. 
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3.7,2 WORKLOAD ESTIMATION 

While numbers of jobs, EXCPs and print volumes are useful 
data in the workload analysis, they provide no yardstick to determine the 
* total workload. The mere fact that 401,053 batch jobs have been run in 
the past 12 months does not provide much insight into workload levels. 
Further, to, state that this represents a monthly average of 50,088 or an 
approximate 1,670 jobs per day or 70 jobs per hour, does not measure the 
demands on the system. The same logic true for EXCPS and print 
volume. What is important are processinPremands per hour in the day 
and hours for each shift. ; These demands are further influenced by 
systems down time and systems and application programming hours that 
must run in unbroken sequences. Resources should be examined closely 
with the view in n)ind of , ascertaining where ajid when saturation occurs. 

3 # B DBTRTOUllQN AND TELEPROCESSING REQUIREMENTS 

DEFINITION ; 

/ Because- of evblying technotogy the hardware environment will 
likely change during' conversion. While from an information system user's 
standpoint ^ automated support remains the* same, changes may be planned 
in. the hardware T cohfiguration. The agency may be considering central- 
ization of multiple site processing or di'stributin^|urrently centralized 
prbcessing. Tliese potential changes in the hai^wj&r"envirbnment and ty£J 
' \* related teleprocessing requirements have to be assessed. 

* . « The systems and applications and^jga file inventories identify 
> A distributed and teleprocessing requirements^Pr^the soiirce system, The. 
> <" workload analysis identifies gross processir^ requiremertti ^ An analysis 
r should be made of the processing requirements for hardware configuration 
alternatives being considered by the agency. It the staff involved , in 
hardware piro6urement do not accomplish # th is analysis, it must t>e done by 
the software convefpiori staff. > : ' v 

, ■ : ; Each, conceptual hardware configuration should be analyzed 

with respect; to software processing requirements. This aidom^ 
number of purposes: -\ * .'. r /vi •; J ; s \ s 

o It assists in verifying that considered hardWate Jconf ifur- 
ations are feasible, l-'O-Cvj 
o It improves the specificity o$ the hardware RFPi; ; v>' 
o It identifies distributed, multiple site, and telep/ofeessihg. 
software requirements. ' \ Vvv"' 

3.9 SYSTEMS SOFTWARE REQUIREMENTS DEFINITION 

Requirements have to be developed for - systems software 
which support applications software and data files.' Included . are 
■ ' compilers,- spooling, utilities and hardware " monitoring^ packages. 
Requirements should be developed as mandatory or ides^le by. the 

■ ;* .v V;; ' ; . ■ ft,;,- ■ : ' ' 
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project team. This serves two purposes: It assists developing the 
hardware procurement RFP and in software conversion planning. Early in 
the planning phase the hardware configuration will be unknown. Planners 
must be cognizant of systems software that they can be assured of and 
that which may or may not be supplied by the hardware vendor. 

3.10 PERSONNEL REQUIREMENTS DEFINITION 

Application system and program, file, conversion tool and 
teleprocessing requirements will be used by the project manager to 
identify the conversion resource requirements. 

In assessing resources the project manager must weigh v ioternal 
resources available against the total workload to determine the adequacy 
of the in-house staff. Once the initial level of effort is estimated and 
outside resources (i.e. contractor assistance) is deemed necessary, cost* 
effective determinations will have to be made regarding where to apply 
external assistance (i.e; planning preparation* conversion, etc.) 

Finally, if preliminary requirements indicate need for outside 
assistance, requirements should be developed for the RFP for software 
conversion assistance (e.g. type of procurement, deliverables, milestones, 
duration, etc.) which will be prepared in the conversion preparation phase. 

3.11 SECURITY REQUIREMENTS DEFINITION 

'i*" SS'es*up£^ V-iBLf^d- "'-pijjiracy -are often overlooked during software 
conversion. A project team review of all agency information systems for 
agency and Federal security "and privacy requirements will assist in 
engineering security features into sensitive software data files and 
software processing during conversion and avoid costly modification Later. 

The basic Federal security requirements are contained in the 
Office of Management and Budget (OMB) Circular A-71, Transmittal 
Memorandum No 1, Security of Federal Automated Information Systems 
(July 1978). In general this regulation requires design and approval of 
agency software of security specifications, security Resign reviews afld 
security testing to comply with A-71 or other applicable Federal policies 
(e.g., DOD security regulations). These policies are pertinent to software 
conversion. If software support is to be acquired commercially, either as 
general purpose packages or converted by a contractor, security 
specifications have to be developed. Additionally, a ri$k analysis is 
required whenever an agency undergoes a significant software change. 
Agency software security requirements have to be compared with this risk 
analysis. The prqjetet manager should enlist the support of the 
information system users and the agency information system's security 
officer in developing security conversion requirements. If an agency has 
extensive sensitive information systems, assistance from an outside 
information system's consultant as an advisor to the project team is 
recommended. 



3.12 CONVERSION FACILITIES REQUIREMENTS DEFINITION 

3.12.1 CONVERSION PROCESSING FACILITIES 

The requirements of accomplishing software conversion on 
systems running production applications have to be developed. This 
applies to conversion associated with hardware replacement as well as 
conversions that are not as§£&iated with -hardware replacement 

■*■> ' „-v ■ , ■ 

The key requirements are to provide conversion processing- 
time and convenient and nondisruptive hardware systems access, 
regardless oJfcitfhether it is source or target, and nondisruptiy^ production 
support to - information system's use?W ' Note : If sensitive processing is 
accomplished on agency computers, security must be carefully considered 
for all alternatives considered. 

Any use of excess capacity on a source target computer for 
conversion will likely be cost effe^tiy^ Additional /advantages include 
convenient location and conversion the source 

system Disadvantages could include; mdohvehient access time. Final 
determination of conversion processihg^f ac iiities will depend upon a 
requirements analysis; ' to de term ine \% ^ have to be 

hired and if production schedules can be adjusted to provide time 
convenient to the conversion project team. Otherwise, alteirriktive 
choices such as commercial time sharing, use of leased, -off site, 
prctfluction facilities, or use of Surplus capacity at another government 
agency should be investigated. ' . ■ ^ : 

If software conversion activities on the 

same system used for production and there are no' feasible, cost effective 
alternatives for avoiding contention between/ production and conversion 
activities, negative impacts ^ystfcbe minimized Thtf project manager 
should consider: * - ; / ^ / \ V 

b Reexaminatibh of application systems to determine if 
soTiie unnecessary systems have been overlooked and can 
be eliminated to provide for additional processing time, 

jo Soliciting the cooperation of information system users 
and agency executives to determine if some information 
systems degradation can be accepted, 

o Examining information systems to determine if 
modifications can produce required information with less 
processing. 

The key management issues here are achieving cooperation 
and support by users and top managers and having sufficient time to 
explore alternatives to any possible hardware contention problems. If 
contention is not resolved, the project manager can expect slippage in the 
conversion and inefficient use of project team resources. 
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3.12.2 CONVERSION TEAM FACILITIES 

Conversion resource assessments will result in estimates of 
the conversion team size, the extent of contractual effort, and whether 
.contractors should be located at the agency or their own facilities. 
Conversion team facility requirements can then be developed. 

3.13 SOFTWARE CONVERBON STUDY PREPARATION 

The culmination of this phase is the preparation of a software 
conversion study. This study, mandated by FPMR Regulation F-492, and 
amended by F-496, provides the justification for the conversion and 
development of the Agency Procurement Request (ADP) for submission to 
GSA for hardware acquisition. There is no specific format presented in 
the software conversion study. However, it is recommended that the 
project manager acquire a conversion study checklist from the Federal 
Conversion Support Center. ; This guide is useful in structuring a study to 
meet agency requirements and to insure completeness. In general, the 
study should include: ; ^ ' r 



Problems ; 

Describe the agency ADP problems which result in the 
need for hardware replacement/software conversion. 

Current ADP Environment 



Describe the fisting systems to provide a basis for 
determining th€ economic and technical advantages of 
the proposed new system or change. This description 
should include the following information: 

Equipment - Itemize all equipment used ; by the 
existing system. 

Software r* Itemize all system and applications 
software including all data files. 

Other Systems Software - Identify all other 
software to include operating systems, utilities 
general purpose software. 

Personnel - Identify skill categories and number of 
personnel required to operate/maintain the existing 
system. 
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o Workload Analysis An analysis of the existing system 
workload should provide a baseline fot 1 determining trade 
offs and advantages of the target system. Processing 
and system requirements should alsoj^described. . 

o System' requirements (i.e., Ith^oitigpft sed ^ ADPE 
: : Environment) 




Describe the r^uirements;^and.' : "^p^y?? ' of the 
proposed target system. * : ^ ( % 

) o Procurement Alternatives v 

" Describe each alternative system in detail^ ; ftate " 
reasons for consideration. Alternatives sh^ldvinQliide 
, fully : \ competitive (noncode-eompatiye)^lk LimitecJ 
competitive (code-compatible), and sdle sodfce. delude - 
projected procurement schedules. * 

o Cost/Benefif Analysis . 

The purpose of the cost/benefit analysis is *to provide 
* management with adequate cost and benefit information 
f to analyze and evaluate the alternative (target) systems. 
I Describe the cost of procurement, training, site 
7 preparation, benchmark, contractor assistance and 

/ conversion for each alternative. State benefits in 

^ • quantifiable terms. Norrquantifiable benefits should 
address organizational objectives, user's satif action and 
improved missions and 'goals, Describe the' risks in terms 
of cost for each alternative considered. 

3 o Recommendations and Implementation S chedule 

State the reasoning and; justification to support the 
recommendation of the selected procurement alternative 
over the other alternatives with axi indepth discussion of 
cost to benefits. Identify consequences of not taking 
action. Include a schedule and milestones for each major 
phase of the recommended system and conversion- ... 

3.14 REQUIREMENTS PHASE MANAGEMENT DECEIONS 

At the conclusion of the conversion requirements phase the 
ADP manager submits the software conversion study for agency executive 
approval This study "will normally accompany and be approved with other 
hardware/procurement related actions, primarily the Agency Procurement 
Request • 1 
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Other agency executive decisions that will be required during 
the conversion requirements phase will be approval anql funding support 
from: 

o Federal Conversion Support Center, 

o Outside resources which might be required to assist in 
Security requirements or the software conversion study. 




COST AND ECONOMIC CONSIDERATIONS 



^ to the conversion requirements phetse, project personnel costs 

will comprise a significant portion of operational costs incurred. 
Additional areas of cost which may be incurred include consultant fees 
such as security assistance or in preparing the software conversion study. 
If operating personnel are used to assist in the software inventory or 
workload; analysis, their costs should be assigned to the conversion 
project' f 

V 

•V • T he software conversion project cost estimates developed 
during project initiation will be refined using the workload, data file and 
program data that is developed. Personnel cost estimates can be 
improved by using the actual, salaries of personnel currently assigned to 
the project, and those propose^ in the future. At this stage in the cost 
estimation process, cost may still be estimated at a summary level of 
" detail, however, as specific cost areas can be identified, (e.g., project 
personnel salaries) this detail should be incorporated into the cQsting 
information. 

In determining the conversion requirements, a major area of 
cost input will be in the assessment of in-house personnel resources, and 
the feasibility of using conversion tools. The assessment of the current 
staffs ability to perform the conversion must address factors such as the 
availability and cost of current staff, potential new hires, and contractor 
personnneL The assessment of staff adequacy should be based upon the 
full cost of the project. In this manner the use of higher cost, contractor 
personnel may be justified if the project duration can be shortened. 
Similarly, the feasibility of conversion tools should address the full* cpst 
impact on the entire project, and not just the cost of comple&ng one task 
in the project. 

Cost input will also be required in the completion of the 
software conversion study where the project budget is detailed by cost 
element, phase, function and year, and a cost-effectiveness analysis of 
the proposed course of action is provided. This study will require a close 
coordination between the cost included in the hardware acquisition 
estimates and the conversion project estimates to assure that all costs are 
reflected, And none are counted twice. 
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REQUIREMENTS MANAGEMENT CHECKLIST 

o ■• FuU-tiroe project manager continues « : " ' 

o Project team staffed with skills for, requirements 
definition 

o Project briefings to top management continued 

o Special assistance/ skills identified 

.-' Security * , 

TeleQommunications 
Software Conversion Study 

o Project team augmentation provided - 

FCSC V 

- Consultant 

o Application system and program inventory extended. . * . 
o Data files inventory extended 

o Potential conversion tools selected, information 
requested 

o Workloads estimated and refined; future workloads fully ' 
projected^ 

o Requirements analyzed from distributed processing 
perspective 

o Requirements analyzed from teleprocessing perspective 

o Systems software requirements developed 

o Conversion" personnel requirements^eveloped \l } 

In-House staff . 
Contractors^ 

o Security requirements defined " ^; > k 

Compared' with vjfew risk analysis ^ ■ r% 

- Information system user input, 1 ^ **v^\ 
Agency information system office input- iv w?.'. ; ^ 

, ■ - Processing requirements doiiblechecked " v " .^''H' 

o Conversion hardware facilities requirements. defined, . ^ 
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Conversion te^ta facilities requests defined 

Software conversion study completed 

Code compatible alternative carefully costed 
Non-code compatible conversion alternative 
carefully costed 

Executive appj$>val of software conversion study 
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SECTION 4 
CONVERSION PLANNING PHASE 

During the conversion planning phase, the prpject team will 
develop the organization and the schedules to be followed in preparation 
for and during the conversion. •» " 

Economic considerations associated with these activities must 
be addressed. The cost information previously developed for budget 
estimates, cost-benefit analyses and feasibility studies and the software 
conversion study will become more refined as conversion activities are 
planned in more detaiL This information can support the preparation oi 
future budgets and conversion plans. 

The importance of planning cannot be overstated. It is, in 
fact, the most important phase. Proper planning,, early in the software 
conversion process, will prevent many problems from occurring, and will 
prepare management for handling the unforeseen contingencies that may 
occur (23, 39). 

The case studies presented in Appendix D reiterate the 
importance of proper panning. Managers who experienced fairly smooth 
conversion efforts had prepared detailed plans, schedules and milestones, 
and tracked performance. On the other hand,, for those conversions that 
had experienced difficulties, the major problems could usually be traced 
directly to inadequate planning. ' Managers, when queried as to how they 
could improve future conversions, emphasized .the need to plan early and 
in detaiL . 4 

' This section describes the activities related to compiling a 

conversion plan. Associated planning costs can be developed in 
accordance with the methodology in Appendix C. The impacts of this cost 
information on management*decisions are discussed as they occur, 

4.1 PLANNING OBJECTIVES 

The objective of this phase is to prepare a conversion plan 
which encompasses all subordinate plans and schedules to prepare for and 
complete the conversion. Conversion plan development requires a 
thorough examination of all activities that must occur prior to, during, 
and after the conversion # ef forts. 

To fleet this objective, the following results must be achieved: 

V * > 
o Plann^g must be ^©tailed, and flexible, 

' 4 o Personnel must be assigned, 

o Facilities must be planned, 

o Schedules must be developed, 

o A reporting hierarchy must be developed, 

o A project tracking mechanism must be developed. 
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4.2 x DECISIONS IMPACTING PLANNING 



Sir 



lring the planning phase there are three major decision areas 
%hich have the njost affect on conversion and that will be made by top 
^agency executives or external organizations: 

jmt o Budget decisions by top management, or external 

- organizations (e.g., Office* of Management and Budget), 

s o Procurement decisions by * external organizations 
• « f (e.g., GSA), ' 

o* Schedule decisions by agency executives. 

4.2.1 BUDGET 
• 

♦ Conversion cost estimates made during the project initiation 

phase feasibility study and the requirements phase software conversion 
study will have been entered jnto agency's budgets and submitted to OMB 
and to Congress for approval and appropriations. .Cost estimates 
developed during the conversion requirements phfese will have also been 
submitted to GSA for review and approval (14, 15). The project manager 
should#*»ontinually review the status of conversion fiscal decisions* to 
determine^ if the conversfbn is approved and any fiscal constraints 
applicabl^to planning^ e 

4.2.2 PROCUREMENT 

T ' — . * - ' 

* * The conversion planning will also be impacted bj^ the selection 
of the target machine. Cost evaluations, Federal regulations and statutes 
(e.g., the' Brooks Act) may* require a competitive procurement (14, 15). 
This could result in selection of non-code compatible hardware, -creating a 
more difficult cc^ersfon hardware, environment, * f 

- t 4 f ■ . I' . \ ' 

*At the initial stages of the conversion planning phase the 
target hardware will be unknown. The project manager must initially 
formulate plans \S cover ••conversion on both code compatible and non- 
qode compatible target hardware. There is no way to avoid planning for 
both contingencies. However, the software conversion study completed in 
the requiremgnts*phase should provide insight j^ito a probable'procurement 
alternative that wi^^e chosen? If there are significant cost savings dfr 
avoidances in a code compatible conversion, %iitial planning emp^sis can 
be focused in that. direction* If cost savings 4re ambiguous, the most 
difficult conversion, non-code compatible, can be assumed. , - ' 

Sometimes in the mid to late stages of ' the conversion planning^ 
phase the target hardware procurementolternative will be known.jjt code 
compatible hardware will be acquired (even though competrtive selectUlh 
has yet to take place) detailed plans can be formulatfetil. U a fully 
competitive acquisition is pursued, much planning Vill have to%ait until 

j : 

»« ♦ 
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the procurement process is completed and the target hardware is 
identified. This condition often places pressures to complete detailed 
plans in a short timeframe, prior to target hardware installation. The 
project manager has to anticipate this contingency. " It is extremely 
important for the project manager to maintain continuing interface with 
the hardware selection staff to gain knowledge of hardware selection 
decisions as early as possible. 

4.2.3 SCHEDULE RESTRICTIONS 

The time frame for the conversion effort may be affected by 
management decisions. Contractual arrangements or. budget decisions 
may dictate seemingly arbitrary installation times of "the target 
equipment or removal of the source equipment To meet overall agency 
needs, management may require the conversion to be completed by a 
certain .date. . The software conversion plans are thus additionally 
constrained. Application of additional agency resources may have to be 
planned to meet the completion schedule, or outside contractors with 
appropriate expertise may have to be used. These actions may affect 
operations and/or the cost of the conversion effort. 

4.3 CONVERSION PLANNING ACTIVITIES 

Figure 4-1 illustrates the activities that occur during the 
software conversion planning phase. During this phase the project 
manager must organize the project team for developing detailed plans for 
the software conversion. Thereafter, the project manager and project 
planning team will: rj 

o Develop a staffing plan to accomplish th/ software 
conversion, 

o Develop a training plan, 

o Plan a conversion schedule and mechanisms to track 
conversion plan execution, 

o Plan for software program preparation, 

. o Involve functional users and top management in 
conversion plans, 
* » 

o Plan for use pf conversion hardware facilities, 
o Provide for location df the conversion team, 
» o Plan for documentation of converted software, 

o Plan for contingencies. 
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ORGANIZING THE PLANNING TEAM . 
STAFFING PLANNING \ 
CONTRACTUAL ASSISTANCrrLANNING 
TRAINING PLANNING 
SCHEDULING AND PROJECT TRACKING 
SOFTWARE PREPARATION PLANNING 
USER AND EXECUTIVE INTERFACE 
HARDWARE FACILITY PLANNING 
TEAM LOCATION PLANNING 
DOCUMENTATION PLANNING 
CONTINGENCY PLANNING 
SECURITY PLANNING ^~ 
TELECOMMUNICATIONS PLANNING 
CONVERSION PLAN APPROVAL 



MANAGEMINT DECISION ▼ 



4.4 



ORGANIZATION OF THE PROJECT TEAM FOR PLANNING 



Before detailed planning can begin, personnel who will 
participate in the planning must be assigned (47). Project team staff 
members who participated in the project initiation and requirements 
phases will normally continue in planning roles since planning requires in- 
depth understanding of the requirements. 

Additionally the project team skills should be extended by 
augmenting the team with: 

. o , Systems Programmers to provide planning details or 
systems processing impacts, 

o Application Programmers who have insight in the 
construction of agency information systems, 

o User T s Representatives wlp will assist in the conversion 
(e.g., during parallel testing), 

o Operational Personnel who will also assist in the 
conversion (e.g., assisting in system testing planning 
schedules), 

o Communications Staff to provide assistance in 
teleprocessing planning, 

o Security Personnel to assist in security and privacy 
planning details. 

» 

* These personnel may participate at different times, and at 
different levels, but their planning input is needed. Where in-house 
specialist skills are lacking, external assistance (e.g., Federal Conversion 
Support Center; consultants, etc.) can be effectively used to shorten 
planning schedules and to develop more detailed, comprehensive plans. 

4.5 CONVERSION STAFFING PLAN 

One of the initial steps is the development of a plan for 
organizing and structuring the conversion project team, (i.e., determining 
personnel to participate in the ponversion", identifying responsibilities and 
developing a management hierarchy). 

, 4.5.1 TEAM COMPOSITION DURING ACTUAL CONVERSION 

Members of the project team during ' the conversion phase 

should includft (SSO: ' " " .*>'.' 

&• 

o* Task Leaders - Senior-level personnel with senior level 
analyst and programming skills at the leadership level, 
preferably with some conversion experience. 
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Senior Systems Analysts/Programmers - Personnel with 
senior level programming skills, preferably with some; 
conversion experience. These personnel should be able 
to assist programmers with conversion programming 
problems. * ■ 

Senior Programmers These report directly to their Task 
Leaders and perform the actual program conversions. 
. . ' * • * V ' ■ '# ■< " 1 

Operational Personnel - Staff memberi rgspd^sibfeffpr , 
operation of source and target equipment. 7 

Vendor/Contractor Support Personnel - Persqnnfcl who 
will train and assist agency personnel during the 
conversion effort. * o 



The size of the conversion project team is dependent on the 
software conversion workload estimated during M the conversion 
requirements phase. ' - - , 



Selection of personnel 
considerations, including: 



dependent on a . number of 



Conversion Experience - prior conversion expeaSenc* is 
important* Even if conversion experience has Been in a 
different hardware/software e^^i^^^ 
insight Is valuable. \ V ^P^M^^C & 



Skills - Expensive selection o 
people will lead to delays/ 
increas^ costs. For this reas 
their most experienced personn 
' It is preferable to assign *persoi 
and target hardware and lan| 
possible, personnel with knoVrL 
and languages jshould gfet priority 



Availability 




Iw-skill level 
ilippage and 
encies assign 
sion duties, 
both source- 
this is not 
rget hardware 



Experience indicates ^fhat perstonel assigned to 
^w^^Version efforts should qpmain vn th.e project until 
vth^ir part is, completed. Plans should provide that each 
staff member be defeated* *to the conversion effo; 
during the time assigned. 9 * 



( . ; rt A .fi^atctx n\^nagementf approach can be .applied to resource 
playpingk yJVIitrix mahagement can ' assist by identifying conversion 
pdn^nnel Jj^^l^l^^i <^>E>^yiqg them to conversion tasks with maximum^ 
effectivprt^^ Figure 4-^llustrates how this can be accomplished; This 
also, assist*™ defining qjjpversion responsibilities.? V* % 
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* PLANNING 



Figure 4-2 
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4.5.2 



ASSIGNMENT OF RESPONSIBILITIES 



Plans should be developed for assignment of responsibilities to. 
all members of the conversion team. This will increase understanding of 
conversion duties eyid reduce the possibility of duplication of effort or 
omission ot important conversion tasks at critical times. 

4.5.3 MANAGEMENT HIERARCHY 

A management hierarchy (see Figure 4-3) should be included 
into the conversion plan for control and project reporting. % 



4.6 PLANNING FOR CONTRACTUAL 

ASSBTANCE/AUTOMATED CONVERSION TOOLS 

An assessment of automated tools and the need for 
contractual assistance was made during the requirements phase. 
Decisions to use automated tools or to obtain contractual conversion 
assistance were based on a number of factors, including: 

o In-house expertise, , * 

o Cost effectiveness, , 

o Internal resource availability, s 

o Conversion time frame. / y , 

During the planning phase it is important to* plan for the use of 
contractors or automated tools. Planning details should specify: 

o When to employ them, 

o Who will use them, 

o How they can be acquired, 

o Where to acquire them, < 

o Training needs. J 

• ' /.■'■■■.-"• 

The requirements for and identification of conversion tools 
will have already been made during the requirements phase using 
guidelines such as those provided by the Federal Conversion, Support. 
Ceriter (40). The emphasis will be on planning the use rather than 
selection. Final selection will only be determined when the target 
hardware is identified.* Likewise, planning details for employment of 
conversion contractors can only be made after target hardware 
identification and fuli assessment of the cost benefits of use of in-house 
resources' vis-a-vis contractor support can be assessed. 
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4.6.1 , PLANNING FOR A SOFTWARE REQUEST FOR PROPOSAL 

TrfpI : ~~ ~ ' ' " 

If a decision was made to J obtain the services of a contractor 
to assist during the conversion* plans have to address (47):* 

o What goes in the RFP, 

o When it is to be issued, '"./* ,. ^ >k< 

o How it is to be released (i.«., competitive,- sole soub$|), 

o . Type of contract (ue., fixed price, cosfplus^ fixed fei^^ 

The experiences of Federal agencies interviewed indicated - 
that the following should be included in a software conversion RFP plan: * 

o- Number of lines of code to be converted, 
o Number of programs, files, applications to be converted, 
. b Conversion schedule, 

. \ o Average effectiveness level and efficiency 6f code, 
"V Documentation, 
o Provision for test data, 
o f Vendor evaluation criteria. 

Prograras, fifes and lines of code are known from data 
developed during the requirements phase. Cost is generally based on fee 
per line of code converted, 0 Most agencies contacted in developing this 
guide, that used an outside contractor, based their fee schedule on this 
scheme. 

It is important to plan a conversion schedule for inclusion in 
the contract. Planning -the schedule is described in Section 4.8. An 
agency should consider including incentives and/or penalty fees in the 
contract. Any penalty fees should reflect the total cost impact to the 
agency of the increased costs of continuing current operations beyond the 
scheduled software acceptance date. A warranty clause may also be 
included. This clause would require the contractor : to provide personnel 
after conversion completion for troubleshooting purposes. 

Agencies commonly specify that a contractor must deliver 
programs that execute a certain percentage of code using test data{e.g., 
70%). This alone does not assure production of efficient or effective 
code. The agency should -consider stating in the RFP an average operating 
efficiency level expected for each program, converted. A number of 
Federal agencies did not include /this in their contracts, and they 
experienced many programs running much longer on target machines than 
source machines, despite the fact that the target machines had faster 1 
processing times. 

The RFP plan should also state what documentation the 
contractor must provide. These should be in accordance with agency 
standards or FIPS PUB 38 or 64.* 
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Provision of test data should be defined in the planning. Most 
agencies choose to develop and provide the data to test contractually 
converted code since agencies have the best insight regarding information 
system processing requirements. If an agency chooses to let a contractor 
develop test data, plans should be developed for agency verification prior 
to te?t data use and acceptance of converted software. 

Planning should allow all statement of work and evaluation 
criteria to be continually refined up to the point of issuances of the RFP. 
Evaluation criteria should be summarised but developed in detail so that 
contractors will, know the exact terms expected for acceptable 
performance. In this regard it is useful if RFP pl^ns are r developed in 
looseleaf notebook form in a format corresponding to a statement of work 
and evaluation criteria. This will facilitate translation of plans into 
contract formats. 

It is advantageous for the project team planning the use; of 
contractors to have contractual experience. If this experience is not 
resident, it must fc^e" gained somehow. One agency, inexperienced in 
managing a software conversion contract; gained experience by releasing 
a preliminary, short-term software conversion RFP. The RFP required 
that the selected contractor convert one application system from 4 the 
source to the target system. This small contract effort servecfa number 
of purposes. It surfaced a number of conversion problems in converting to 
the target system, provided the management team experience in 
conducting a conversion, and also provided the experience in managing a 
software contract. Additionally, this approach produced insight into 
additional performance criteria and schedules that were translated into 
planning the major software RFP. 

* . ■ s '■ • ' 

4.6.2 , CONTRACT MONITORING 

During the planning phase, a mechanism should be developed 
for monitoring the contract. If the contract is large enough," the project 
manager shouKT be assigned as, or have assigned on the p&ject , 
management tebni, a full-time Contracting Officertfl^Technical 
Representative (COT R). • r < 

4.7 ' PLANOTNG FOR TRAINING 

A training schedule for the project team as well as the entire 
software staff should be developed. Training itself should begin and end 
prior to the conversion. Haweyer, if carefully planned, training can 
extencl into th^conyersion phase. Proper training of personnel and 
adequate traiijmk schedules are 6f major importance in keeping the 
conversion procl^Lon track (33 )^ffhe impact of training conducted too 
late is apparef a ^ pb aff is being Trained when they should be converting 
software. Wh^Sra&at well understood is that training can be cc^iducted 
prematurely. The^ttiie lapse between training and conversion degrades 
effectiveness. 

8k " ... 
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Following is a checklist * of conversion traitting plan 
requirements. Based on this checklist, tljef project planning team 'should 
develop a detailed training outline, the 'Hntent of each subject area and , a 
training schedule. Training should incli^^ fiftl conversion and operational 
personnel, and functional users. The projefet manager should coordinate 
training plan schedules with all concerned to ensure that the content and 
schedule meet agency requirements. ' . . 

Training Requirements . ' /. - 

^ o Conversion ^ids/automated tools 

o Target system software 

■ Compiler differences > . 

Disk file management 
- New peripherals 

Utilities . 

o Target hardware < 

Operation 
* - I/O procedures 

" Data format 

o %■ Program changes (programming conventions, code and 
I/O differences) V * , ^ 

~ -.' * „ • * ■ 

o Data * 

... .. \ ■ ... . y-.' * • •■>;:, * 

z . - Collating sequence * * % 

■*\ — . Logical compare differences 

\ o Program job control language 



Instructors ■ 



Training facilities • A 



V 



Training planning will require coordination withi contractors. 
The hardware vendor should' be made responsible for training^ersonn^ on 
use of the neW v equipment (operations, procedures, software) and 
describing differences between source and target equipment Instruction 
on use of automated tools may require training by the supplying vendor o; 
if developed internally, by in-house persojineL 
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4.8 PLANNING THE SOFTliirABE CONVERSION SCHEDyLE AND 

DEVELOPING PLANNING TRACKING MECHANISMS 

A schedule of system and program conversions must be* 
established. An inventory of all applications and programs was made 
during the project initiation and conversion requirements phases. This 
established the number of programs, files, and number of lines of code by 
language and thf level of conversion effort (in terms of jnan-hours) each 
program or systeitf will require. Using this inventory, the project planning 
team should establish the schedule for converting these programs, 
whether done in-house or by an outside contractor. 

4.8.1 SOFTWARE CONVERSION PRIORITY 

The first step in. scheduling is to determine the ..order of the 
files and programs to be converted and results expecteci in a chronological 
list. ... ~ . ■ :• ■ • ■'•■y/^C.. ° : 

Top management or functional users may require some 
systems to be converted earlier than 1 others b^pause of future^ agency , 
plans. Users may also request that thfeir systems be transpprted to target 
hardware as sobn as possible to take advantage of its capabilities. Based 
6n these parameters, plans must be developed around resoqrce 
availability. 

4.8.2 ' RESOURCE PLANNING AND RESPONSIBILITIES ; . \ , . < 

Plans must permit conversion to coincide with the availability 
of resources, including get^piH)^ : equipment, funding, and processing 
time.> This precludes ^^^ifent situations from developing which 
contribute tp slippage ah^5^^V , erruns, Such as: 

. ■ Km^/ ' ' ■ . ■ ■ -.. ' 

o tj'ardwar|^:?av&i^^ but files and- programs not b'eing 
? ' converted, * , ' ; 

o Files and programs in* a state £ of conversion but no or 
insufficient processing resources. / j v 

This will prevent potential future problems in terms of 
overlapping responsibilities and provide accountability for the various 
systems, programs and files earmarked for conversion. ,f 

4.8.3 SCHEDULE PLANNING \ t 

A detailed schedule of applications, programs, and files to be 
converted should be established regardless of whether conversion is 
performed in-house or by an outside coatV^ctor. A number of methods 
can Sensed to do this, .but they all have common features, v : 4 
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o o Identify personnel responsible for application program 
file conversion. ♦ 1 

o Fstablish timeframe for conversion. ^ 

o Establish deliverables or results (e.g., code translation, 
Unit, system and parallel tests). 
\ 

o Fstablish a progress reporting mechanism and tracking 
system. 

Four typos of schedules should be maintained, and tracked. 
These schedules serve as cross-references to each other (33). They anp: * 

o Application system conversion schedule, 

o Application program conversion schedule, 

. ' " o File conversion schedule, «..'-, ^ 

o Personnel schedule. ' 

Figures 4-4 through 4-7 are sample Yoi'nis/.-itmt may be used 
for scheduling activities. 

4.8.4 V KFPO KTINCi M F CHAN IS MS -TRACKING AN I) MONITORING 

<v ■ — ■ , 

To maintain control and awareness of project status the 
project manager will want to establish a mechanism by which project 
status is tracked and reported laterally and upward. At the project team 
level reporting is most detailed and should contain: 

' o Program /application file name, 

o Individual's name responsible for conversion, 

o Start date/completion {late, 

o i urrent status,' 

o . Fxpected completion date, 

o Problems. ^ 

The detailed information at the project team level will be 
supplied by the task, leaders for each activity for which they are 
Responsible. For higher level reporting, the project manager will 
jsunimari/.e project status information and disseminate to top management 
in regular reportsi 

As shown^m Figure 4-8 a number of tracking mechanisms are 
available, both automated aru^f manual." Selection of a method should be 
based on requirements and policies of the particular organi/atipn, and "bV ^ 
the project manager's management style. I he important point here is to* 
establish this mechanism arid integrate it into software conversion 
planning. 
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APPLICATION SYSTEM CONVERSION SCHEDULE*. 




SAMPLE APPLICATION SYSTEM SCHEDULE 
Figure 4-4 



Source: U,S. Army Guide 

for Software Conversion 
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APPLICATION PROGRAM CONVERSION SCHEDULE 
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SAMPLE APPLICATION PROGRAM SCHEDULE 

Figure4-5 * 

** 

Source: U.S. Army Guide ^ Note: All programs for each 

for Software Conversion application not shown. 
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Source: U.S. Army Guide 

for Software, Cqnvereion 
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SAMPLE PERSONNEL ASSIGNMENT SCHEDULE 
Figure 4-7 
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PROJECT MANAGEMENT TRACKING PACKAGES 
Figure 4-8 




Theltracking mechanism should also provide cost performance 
information forWch activity such \s estimated budget, actual expenses 
to-date, and variance between estimated and actual costs. Variance 
criteria could be established that would flag potential cost overrun 
conditions for early, management attention. ^ 

Figures 4-9 and 4-10 illustrate-~sample tracking charts that 
may be used by project managers. Figure 4-9 is a periodic (weekly, 
biweekly, etc.) report indicating, the status for : each program (application, 
file). The chart is completed at regular intervals by the project manager 
for a summary overview of the entire conversion. Figure 4-10 is an 
application tracking chart that can be used by task leaders and the project 
manager to' keep track of each program within the application. 

4.8.5 MULTIPLE SITE CONVERSION SCHEDULES 

Management of conversions at multiple sites (e.g., in a 
distributed processing environment) presents ^ditiohal problejns. ,,If 
centralized control cannot be exerted, tracking and monitoring progress 
for a multiple site conversion will be difficult. In multiple^site conversion 
planning it is essential that top executives assign responsibility for 
maintaining schedules and reporting conversion progress. 

4.9 SOFTWARE PREPARATION PLANNING 

The condition of software and data fijes, prior to conversion, 
might be such that they caiyiot be efficiently or> effectively converted. 
Preparation. activities have to be planned (27, 39) including procedures to: 

o Update documentation, 

o Remove obsolete programs and code, 

o Develop test data, 

o Modify programs, as required, prior to conversion. 

During the "conversion requirement^phase, documentation was 
reviewed for completeness and accuracy. Since poor documentation 
directly affects conversion effectiveness, corrective action must be 
planned and tracking mechanisms* should be developed to ensure 
documentation requirements are met. ( ^ 

Plans to allow for t\\e removal of obsolete programs and code 
should include notification M users that their asistance is required and 
solicited in a positive, participatory role and obtaining support from top 
management. . * < 

t . Test data development planning is' extremely important . It 

affects the accuracy and effectiveness of the converted programs and 
considerable develop nrental lead time is often required^ This is discussed 
in more detail during the conversion preparation phase. 
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SAMPLE WEEKLY PROGRAM STAJUS REPORT 
'I Figure 4-8 f ' 
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SAMPLE WEEKLY STATUS TIMELINE 
Figure 4-10 
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Program modification activities should be included in the 
conversion plan. These activities are listed below. 

o Language Translation 

The experience of some Federal agencies indicated that 
language translation should occur prior to conversion, if 
possible, (e.g., Assembly language^ to COBOL for a 
COBOL to COBOL conversion) 

o Enhancements 



If new user enhancements and functional redesigns are 
required, they should preferably be scheduled prior to or 
after conversion, and not during the actual conversion. 

i o Removing Vendor Extensions. 

' • N All programs should have been examined for vendor 

specific extensions during the requirements * phase. 
These should have been identified and documented. 9 
Conversion planning should allow time for the removal of 
vendor specific extensions and coding, if possible. 
However, vendor extensions may provide capabilities 
that standard languages do not. It may not be possible to 
remove these extensions and still provide the same 
output. Redesign activities may be required. 

o Optimization 

Programs should be examined for efficiency. If 
optimization is warranted, plans should be developed to 
streamline code prior to conversion. This reduces actual 
conversion time and ensures production bf efficient 
software. 

4.10 FUNCTIONAL USER,AND EXECUTIVE INVOLVEMENT 

S Functional users should be involved throughout this' phase, 
since their cooperation is essential for a smooth conversion effort. Users 1 
should be included in planning for scheduling and testing (47). The cost ok 
user committee 1 or work group, should be included in^the total cost of 
conversion, and the size and involvement of this group should be 
determined partiality on cost considerations. 

It is unlikely that agency executives will w°ish to be involved in 
the conversion planning details. However, the project manager should 
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ensure that agency executives are continually apprised * of planning 
progress. This level of management can lend significant support and 
assistance in resolving many plaffiiing^conf licfa that will occur outside the 
authority of the project manager or ADP manager. 

4.11 HARDWARE ACTIVITIES 

The project team must stay abreast oi\a!l activities relating to 
the hardware procurement, since these activities will affect the 
conversion plans. 

* i • ' • 

The hardware procurement decisions will impact planning and 
conversion costs according to the selection of the target environment 
equipment, and the availability of the target equipment for installation, 
testing, and operations. 

- -It is recommended that agency staff involved in hardware 
acquisition regularly participate in software conversion planning 
conferences. 

The project manager must plan for production and conversion 
processing. A number of options are available for conversion and should 
have been identified on an operational and cost-effectiveness standpoint 
during the/requirements phase: - ' 

o On target hardware colocated with source hardware, 

^ o On target hardware located in another facility, 

- o Through time sharing on hardware provided by the target 
vendor, f ■ „ - 

o A combination lof the above alternatives. 

If the target hardware is not installed prior to. the start of the 
conversion, time sharing arrangements on a compatible' machine will be 
required. The hardware RFP may Require the vendor to provide these 
services, or a commercial timesharing serviee may, have to be used. 

The target hardware /may have to be initially installed in 
another location if source hardware is still required for production and, the 
current computer facility is too smalL This jvill require providing another 
facility and all appropriate services, e.g, air conditionings power, raised 
floors. . ' 

The selection of production and/or conversion facilities is 
dependent on a number of variables, including cost, availability, and time 
frame. Preparing another .computer room is expensive, requiring detailed 
planning and contract work. If the target computer is placed in another 
facility, the conversion team may have to reloeate. 
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^ ^ costs: 



Use of a timej|hMB may result in two. additional 




o Equipment^ II, modems) required r to interface 
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with the 
o Computer time. 

4.12 PLANNING FOR LOC^UJG THE CONVERSION [TEAM 

Plans must be prepar^for providing facilities to house the 
conversion team.. Sufficient spajftShay be available to house the planning 
team as a group, but not be lai^^pteugh to accommodate the conversion 
team. If members of the team are located- in a number of different 
places, it will be advantageous to move them to on6 location during the 
conversion effort to increase management control. If converted programs 
are to be run on hardware located external to current facilities, it may be 
advantageous to temporarily relocate the conversion team to or near that 
facility. - . 

4.13 PLANNING FOR DOCUMENTATION OF CONVERTED - 
. PROGRAMS j ^ 

Plans should specifically * require the conversion team to 
produce documentation in accordance with FIPS standards or guidelines. 
Additionally, plans should provide sufficient resource^ and time for 
documentation production. If contractors are to be used for software V 
conversion, RFP planning should be reviewed to ensure documentation 
requirements are addressed. Documentation improves software * 
maintenance on a day-to-day basis and significantly aids programmers tend « 
analysts in software conversion. 

4.14 CONTINGENCY PLANNING 

To reduce the likelihood) of problems occuring during 
conversion, continuous review of plans for potential problems can assist in 
early identification and resolution of many otherwise disruptive influences 
before they occur. No conversion will be problem-free, however. The . 
project manager should expect problems and develop a plan to handle 
those contingencies as they occur. O 

During conversion most unanticipated problems occur due to: 

o Failure to Maintain Conversion Schedules Schedule 
slippage can be significantly reduced if plans provide 
adequate resourced in terms of personnel and time to 
accomplish conversion activities. Problems are further 
reduced' if specific staff capabilities and limitations are 
considered in developing schedules and assignments. 
However, the project manager must anticipate that some 
personnel will fall behind schedule. 



. ■/ . . " .. . . ... d I 

. • v ' * b, Personnel Changes Unexpected losses dt personnel will 
J occur due to sickness^ extended vacations, g transfers ej\d 

' termination. . .* * ■ ; ' , 

o f Scheduling Deficiencies Because ^quirements can never 
be perfectly defined, 4 spme schedules will be developed 
thai are too rigid or unrealistip/ * 

. o v " Contractor-Related . rP?obIe)rns Contractors frequently 
\ * fatUbehind schedule 6c epnvertatf programs may ^require 

more'optimization than anticipated. * s ^ 

' ^ ' ' ■ 

o Hardware Delivery and Installation Delays , Hardware 
installation .may be delayed due-, to contractual 
difficulties, transportation delays due to "strikes, 
manufacturing difficulties or . \profc>lems in ^site 
preparation. . . \ 9 

Plans should provide a ''reserve" of personnel resources and 
time to permit „the project manager the flexibility to adjust schedules and 
levels of effort to meet contingencies on a case-by-case' basis and still 
f accomplish conversion by^he established end date. Task order contracts 
can also be negotiated prior to conversion to apply contractors on a'quiek 
reaction basis in resolving conversion problems. 

* The use of a. detailed costing structure as described in 

Appendix C can assist th6 project manager in contingency planning and 
\ execution. % Potential and actual problems can be analyzed and 
alternatives selected at the lowest overall cost to the agency. 

If contractors are going to be used to convert software the 
potential for problems can be reduced by detailed planning of the RFP in 
terms of expected deliverables, documentation, and software 
performance. Penalties or award^in the contract are recommended to 
provide incentive, for the contractor to stay on schedule and perform 
effectively. 

" r . • • 

4.15 SECURITY/PLANNING 

\ ' Security plans should x be developed to meet requirements 

developed during the requirements phase. Specific areas which require 
planning attention include: 

■ ' ^ ' 

o -Identification 'of security software features which meet 
the^fleeds of the risk analysis and assignment of 
convei^ori team responsibilities for inserting security 
features into spftware and procedures during conversion, 



101 



79 



iccess control to sensitive software, databases, system 
libraries and documentation, 

- ,„..;.( 

o Isolating software testing and the' use of honrsensitive 
data from the operational environment, 

o Software security assur^Qce and certification, 

o Conversion team security trainings 

•* r o Personnel clearances to include contractors and 
ponsultanis, 

o Operational procedures during testing and cut over, 

o Facility requirements for sensitive sVftware conversion 
" , products (e.g., locked cabinets, safes for sensitive 
I listings, .etc.), * 

o Security specifications in the RFP that must be 
addressed by the contractor, 

o Teleprocessing, multi-?ite and distributed processing 
security. 

NBS FIPS PUBS 31, 41, 48, 65, and 73 address security and risk 
management considerations which may be helpful in dealing with security 
needs during the planning stage. These FIPS PUBS are ^described in 
Appendix B. 



4.16 TELECOMMUNICATIONS PLANNING 

Plans and schedules must be deyeloped to assure that the 
converted software and data files can interface with or be supported by 
teleprocessing hardware and software environment. 

4.17 FORMAL CONVERSION PLAN 

All the activities described in this section should be 
incorporated into a formal conversion plan which will serve- as the guide 
during the conversion process. Figure 4-11 is a candidate outline of a 
conversion plan that can be used as a guide by project managers. 

The conversion plan should answer the questions of: 

o Who shall participate and conduct the conversion? 

p When will the conversion take place? 

o Where will the conversion take place? 

o. How much will the conversion effort cost ? 
* ' * " m ~ r ~ ' 

It is recommended that the plan be developed in draft-form 
and coordinated with the hardware acquisition staff and information 
system users prior to presentation to agency executives for approval. 
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Section Description 

^ 1 4 Background 

• 2 Summary of Workload Analysis 

4 <s 3 ^ Budget Summary 

4 ' Personnel Resources 



- Management Team 

- S/W Conversion Team 

- Availability 

Conversion Schedule 

- Responsibilities 

- Schedule 



6 4 Project Reporting and Tracking 

7 Conversion Aides ^ • « 

8 Software Contract , 

9 . Training Plan 

- Security Plan 

- Telecommunication Plan 

10 Facilities Plan 



iduction 

- Conversion 

- Team Location ' 

& - Equipment Resources 

11 Contingency Plans 

Appendices Budget Schedule 



SAMPLE OUTLINE OF CONVERSION PLAN 



Figure 4-11 
i 
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4.18 PLANNING DECISIONS- / 

,At the conclusion of the planning ghase this conversion plan 
will, be presented to agency executives for approval, to proceed with % 
preparation and conversion activities. It is recommended that the plans 
, be presented as part of a formal briefing where the entire plan can t be 
explained and an appreciation gained by top management for planning 
ramifications and impact^ on overall agency operations. 

Once plan approvals are gained other management decisions 
will involve approving conversion preparation and conversion budgets and 
implementation procedures associated with conversion preparation, the 
next phase. 

4.19 ECONOMIC CONSIDERATIONS 

During the conversion planning phase, personnel costs should • 
continue to be the major element of cost. Outside consultant services' 
Tnay also contribute to the cost of this phase if these services are used to 
assist in the planning effort in areas such as developing the conversion 
plan, reviewing the conversion plan or actually preparing the formal 
conversion plan for submission to upper management. Expanses may also 
be incurred in the acquisition of automated project planning, tracking and 
reporting aids. 

In this phase, the cost estimates developed for the software 
conversion cost structure will be refined as conversion activities are 
defined in more 'detail. Cost information should be developed at the most 
detailed level that is anticipated to be required. The accuracy of 
individual cost estimates at this level may not be great; however, the 
overall accuracy of the total cost of conversion should improve due to the 
use of more detail and the ability to estimate future project costs using 
the £ctual costs incurred during the previous phases. 

Conversion Gost information will be used during this phase to 
assist project management in developing the conversion schedule and 
resource assignments. Scheduling decisions should be based on total cost 
considerations that include the, entire procurement action, not just the 
software conversion effort." The detailed costing methodology given in 
Appendix; C can assist in the assignment of resources to the conversion 
effort by allowing a cost-benefit analysis regarding the use of outside 
personnel resources for conversion functions. Also, the conversion cost 
information will assist the preparation of the formal conversion plan by 
providing detailed cost information for budget planning by developing 
budget schedules by function, phase or»yeaf; developing alternative cost 
justification^ for the use of outside contractors and conversion aids; 
providing continued justification for the conversion effort; and ensuring 
the cost-effectiveness of contingency plans. 
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PLANNING MANAGEMENT CHECKLIST 

o/ Planning team assembled 
o On-going costs being tracked 

o Team augmentees identified . , . 

System programmers 
'Security 
FCSP 

Consultants / 
Telecommunications 
' Others 

o Coordination and interface on-going with hardware 

acquisition staff 

■ ■■ ■ i 

o Budget available to support planning 

o Project planning constraints identified 

Budget constraints affecting conversion 
Hardware procurement 
Time and schedule limitations 
Others , 

p Cbnversion staffing plan developed 
In-house staff 

External conversion resources 
o Training plan developed 

o Plan for use of contractual assistance and conversion 
, tools during conversion completed 

RFP planning 

Tool acquisition, training and use planning 
Contract monitoring # 

o Software conversion schedule planned * 

* - Priorities considered f 
Conversion responsibilities assigned 
Schedule developed 
Information system user input 
Multiple site schedules considered 

d Conversion plan tracking mechanism developed 
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o Software preparation plan developed \ 

Documentation updates 
Removal of obsolete programs and codes 
Test data * 
- - Preconversion program preparation 
Optimization 

o Continuous interface with agency executives and 
information users ' • 

o Conversion facilities planned 

o -Locating conversion team planned 

o Documentation production planned 

o Contingency planning accomplished 

o Security plans developed 

o Telecommunications and distributed processing plans 
accomplished » 

o Conversion plan drafts 

Internal agency coordinationor 
Agency executive approval 




SECTION 5 
CONVERSION PREPARATION PHASE 



This phase is .a direct continuation of conversion planning in 
that many of the plans made during that phase are acted upon. At the end 
df this phase, the project manager will have accomplished all activities 
that are required to begin actual conversion (23). > <\ 

On a timeline of conversion activities, the preparation phase 
may be significantly overlapped by conversion planning on one side, and 
the conversion phase on the other. This is illustrated in Figure *5-l. 
However, the activities or functions that occur during preparation are 
distinct from plannirfe or actual conversion activities. Thujs, preparation 
is discussed as a separate phase. 

While preparing for the^ conversion, the project manager must 
continue to monitor project cost performance relative to the initial 
budget established during project initiation. The preparation activities 
may require significant expenditures over a- short time period as the 
conversion staff is acquired, facilities and equipment obtained and 
conversion tools developed. Due to the change in magnitude of conversion 
related expenditures, the project manager may find it necessary to track 
project costs closely and report regularly (e.g., monthly) to top executives 
to assure them that cost controls are being used. By comparing software 
conversion preparation costs estimates against actual costs incurred, the 
project, manager will be able to refine cost estimation data and 
procedures. This will permit more accurate projection of conversion costs 
in future phases and future conversions. 

During this phase the project manager will begin to se^areasv 
in the conversion plan that need improvement or revision. The conversion 
plan, however, should have the flexibility to allow for changes, and 
modifications by the project manager when needed. 

5.1 OBJECTIVE 

The objective of this phase is to complete all activities 
necessary for the project team- to commence conversion. This objective is 
accomplished by following the convers\pn plan and conducting all 
activities that, if not accomplished, would interfere with or impede the 
conversion effort. These include assembling the staff, training, obtaining 
software tools, obtaining contractual assistance, and obtaining* facilities 
and necessary equipment. 



85 t*£ 



9 



CONVERSION 
PLANNING 



CONVERSION 
PREPARATION 



PHASE INTERACTION 



Figure 5-1 
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5.2 DECBIONS IMPACTING SOFTWARE CONVERSION 

The project manager must be aware of, and prepared for, 
decisions made by top management and external organizations. New 
decisions may be made that affect the conversion effort. The conversion 
plan and schedule will have to be modified based on these new decisions. 
For example, the budget may be changed, forcing the project manager to 
change conversion schedules. The target machine may be changed, 
forcing a change in scheduling, staffing, and training. 

By continually addressing the full cost of the conversion 
effort, the project manager will be in a position to correctly relate the 
conversion cost impact of these 'external decisions to agency executives 
and involve this level of management in the total conversion effort. 

5.3 CONVERSION PREPARATION ACTIVITIES 

Figure 5-2 illustrates the major activities that occur, during 
the preparation phase. They provide the framework for the subsequent 
portions of this section, and include the following: j 

o The conversion budget must be approved, 

o Work packages must be developed, 

o The project team must be assembled and assignments 
disseminated, 

o The training staff must be assembled and training must 
start, 

o Contractual support, if needed, must be obtained, 

o Software tool£ must be obtained or developed, and team 
members trained in their use, 

o Equipment must be obtained and located with 
appropriate users (e.g., terminals), 

o The project team should be located in the facilities to be 
used during conversion effort, 

o Test data an^ files must be developed, 

o Program modifications should be started, 

o Documentation should be updated, 

o Hardware procurement should be monitored, 
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Figure 5-2 
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o Users 1 and agency executive's conversion responsibilities 
must be coordinated, 

o Progress must be tracked throughout the phase, 

o Problems as they arise must be addressed and the 
conversion plan modified as needed. 

5.4 BUDGET APPROVAL 

It is imperative that prior to beginning costly preparation 
activities, project management obtain final approval for the budget. This 
final approval should reflect any recent budgetary changes and financial 
reporting requirements desired by management In previous conversion 
phases, costs were primarily related to personnel Costs will climb during 
the preparation phase as the larger conversion team is being assembled, 
contracts are awarded, and equipment and facilities obtained. 

5.5 DEVELOPMENT OF WORK PACKAGES 

The project manager and team leaders will develop and 
assemble comprehensive conversion work packages to facilitate 
conversion (45). 

Work package preparation includes the effort to physically 
assemble all work packages and to establish an inventory and control 
system for the work packages. Each work package should contain enough 
information to enable the converter to adequately define what is to be 
converted (programs, files, control stream language, etc.), to ascertain 
the system/subsystem functions, to identify all system/program 
documentation needing to be redocumented, and to execute and test the 
converted system/subsystem to guarantee conversion was successful. A 
work package should be large enough to encompass a functional area (a 
system or subsystem) and should be made up of information describing the 
overall package (system/subsystem) and its individual components 
(programs, files, etc.). The content and makeup of individual work 
packages should be determined for each conversion, but will typically 
consist of such items as: 

o 1 Work package transmittal sheets, 

o System/subsystem descriptions, 

o System/subsystem test data and descriptions, 

9 System/subsystem control stream language job streams, 

b System/subsystem run documentation, 

o Program inventory forms, 

o File inventory forms, 

o Program descriptions, 

o Source and compile listings, 

o File descriptions, 

o Program test data, 

o Program documentation, 

o File documentation. 
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5.6 ASSEMBLE CONVERSION TEAM 



Conversion team members who will work on the conversion 
must be assembled or notified during this phase (47). Each person must be 
informed of: 

o When their conversion work will ffegin, 
o To whom they will report, 
■ o Other members of the project team, 
o Reporting mechanisms to be followed, 
o Areas of responsibility, 
o Schedule for completion of tasK§, 
o Priority ranking of assignments, 
o Training schedule, 

o New work locations, if applicable, — 
o Equipment available. 

Project managers may find it helpful to notify the conversion 
staff htembers and inform them of their responsibilities using a form or 
written format* This will improve understanding and ensure all pertinent 
information is conveyed to £eam members. An initial group meeting is 
recommended to discuss the overall goals and objectives of the conversion 
effort. Thereafter task leaders can then meet with their respective staffs 
and disseminate detailed information to each individual. Project team 
members should be made aware of the fact that they will be dedicated to 
the conversion until their particul|£i\duties are completed. 

Task leaders should hold regular meetings with their staff to 
discuss progress and review any problems which may arise. • 

Project team members wilU)e furnished work packages as part 
of tasking. Project team members Should review their particular tasks, 
and notify their task leaders if they foresee any problems (e.g., not 
enough time scheduled for a particular program conversion). The 
problems that surface may require modification of the conversion plan. 



5.7 TRAINING 

The project team members should be scheduled for any 
training that is required. If on-the-job training is to be used in lieu of 
formal training courses, some initial productivity loss can be expected as 
the learning curve is gained. If on-the-job training was not considered 
during the requirements phase, the conversion plan and schedules will 
require adjustment. In addition to the conversion staff, training will be 
provided operational personnel, functional system users, and other 
members of the ADP staff, not involved in conversion, but who will 
ultimately perform software-related work on the target system. 

The project*manager must acquire and provide the instructors 
to train the conversion staff and ensure that training plan objectives have 
been met (33). Except for very large conversions, one to two 

I - 
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instructors should be sufficient. Multiple-site conversions may require 
more trainers if software conversion is decentralized or if a constricted 
conversion schedule requires concurrent training at two or more locations. 

System programmers should, make Special training 
presentations, as required, to inform the conversion team of systems 
programming impacts on application software. Also, any security-related 
training should be accomplished. x 

5.8 OBTAINING CONTRACTUAL ASSISTANCE AND 

AUTOMATED CONVERSION TOOLS 



riWc 



5.8.1 PREPARATIONS FOR OBTAINING CONTRACTUAL \ 

ASSISTANCE ) 

Any planned putside assistance must be* (gained during this 
phase. The project manager will have to provide assistance in or 
accomplish: 1 

St 

o Preparing the software conversion RFP, * 
o Releasing the RFP^J 
o Evaluating proposals, 
o Selecting a contractor. 

Plans for these activities were niggle during, the conversion 
planning phase including planning the specific content of the RFP. 
However, contractual procedures in obtaining software conversion support 
can take from four to six months from time of*issuance of the RFP. The 
contract m\^st be solicited, evaluated and responded to^y vendors, 
negotiated and awarded. The potential for time delays is great. It is" 
essential that contractual assistance be obtained on schedule because 
slippage in this area may force slippage of the whole conversion ef fort. 

The selection of#f contractor to assist in the conversion 
process is critical since the contractor's ability will affect the outcome of / 
the entire conversion effort. Contractual evaluation factors, applied in I 
this phafce include, but are not limited to: 

o History of Company 

Specifically how long has the vendor been in business; 
financial standing; soundness of corporate^ management 
^ practices; background of corporate management. 

) A ' 

**** b Experience 

Types of conversions the vendor has been involved in; 
success; problem resolution methods; familiarity with 
the agency target hardware environment. 
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o Personnel 

The skill and experience level of the employees; turn 
over ra\e. 

o Cost, Deliverables and Responsibilities 

> * 

Th§ proposed deliverables and schedule; responsibilities 
assumed by the contractor; contract cost. 

o " Testing \ 

Ability of the c6ntractor to meet test objectives; 
proposed alternatives; acceptability of alternatives. 

» After selecting a software^ contractor, meetings should be 
held with their representative. It is important that lines of communica- 
tion be kept open and that ^misunderstandings be quickly detected and 
resolved. Since a contract statement of work can never completely 
address all contingencies that occur during the conversion, it is important 
to develop and maintain a professional, cooperative working relationship 
with the contractor. 

The contractor should thoroughly understand how progress is 
going to be monitored, and how performance penalties or awards will be 
determined. This includes identifying to the contractor which staff 
members responsible for specific areas of the conversion are contractual 
points of contact. 

5.8.2 AUTOMATED TOOLS f | 

Automated tools, if used, must be obtained or developed 
during this phase. If they are to be obtained from a commercial source, 
another RFP may have to be released. (Note that the decision, to develop 
the tools in-house or obtain them from an outside' source was made in 
earlier phases.) Potential contractors should be required to perform a live 
test demonstration on a sample program prepared by the project team. 
Results should be evaluated for accuracy and efficiency and based upon 
the full cost impact of - each proposal on the total software conversion 
cost. The cost of the automated tools should be compared to original 
estimates and, if significantly greater than the estimates, their costj 
effectiveness should be reevaluated. 

If the tool is to be developed in-house, a staff must be 
assigned to develop the tool as well as tool verification data. Data 
processing resources must be made available to the developers. After 
tools have been acquired br developed, the conversion te&ffi members 
must be trained in their use. 
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5.9 LOCATING CONVERSION TEAM/OBTAINING EQUIPMENT 

d • • 

Project team members should be located in^their team 
facilities. New offices should be equipped with adequate furniture -desks, 
chairs, lights, telephones. The project manager should ensure that 
adequate resources are available to those team members who require 
moving assistance (e.g., boxes, transportation etc.),(4). 

Relevant data processing equipment t^at project team 
members may require (e.g., card files, terminals, modems, and telephones) 
must also be obtained. These should be in place and tested prior to 
starting the actual conversion process. 

5.10 CONVERSION FACILITIES ^ 

Management must obtain conversion facilities, and develop 
procedures for use. Information distributed to the project team prior to 
the conversion should incline: 

o' Location of facilities, 

o Operational procedures, 

o Hours available, 

o Points of contact, 

o Access and security issues, 

< o ADP communications, telephone numbers, 

o Logon procedures, * 

o Protocols and passwords required to log on hardware, 

o Troubleshooting procedures. 

5.11 DEVELOPMENT OF TEST FILES AND DATA 

Good test data should be developed prior to code conversion. 
If the conversion is to be done totally in-house, project team members 
will have to develop the test data. A management^ question arises, 
however, when a software contractor is used. Who should develop the test 
data, the contractor or the organization? All of the organizations 
interviewed in preparation of this guide developed their own test data. 
However, it may be^asible for the contractor to develop the test data 
for agency review and validation. Deciding who should develop test data 
will have been accomplished during the requirements phase. Whether test 
data is developed by an agency or contractor, it is important that 
information systems users have the opportunity for input and review. 

Test datQ preparation and generation includes all creation, 
preparation, and generation of test data sets to validate the converted 
programs, files, and systems (45). It should ensure that unit test data 



^93 



115 



sets are small enough in volume to minimize testing costs, but thorough 
enough '"to exercise at least 70% dt the logical paths of the program. 
Several studies have Independently shown that typically a system will 
spend 50% of the run tim^in 4% of the object code; and 10% of the code 
typically will account for 90% of the run time. The implication is that 
90% of the testing may only be exercising 10% of the code. Thus, 
ensuring that about 70% >f the logic paths are executed may still be 
inadequate. The 70% tested must include the code that is typically the 
most frequently *used. Preparation of test data for execution of the 
programs following clean compilation should stress the use of data that 
will execute a maximum amount of the program logic with a minimum 
amount of input data. Because test data are usually prepared and 
generated on the source computer, their preparation and generation 
should include the conversion or transfer of the test data files to the 
target computer so file comparisons can be performed. 



Any additional modification of programs should occur during 



o Remove any obsolete programs and code. This will 
require team members to interact with users. 

o Program desired user enhancements into the system in 
advance of conversion. It would be preferable to do this 
after the conversion. However, if time allows or 
enhancements are, mandatory, changes should be 
accomplished during this phase. 

o Remove vendor extensions from the code. However, 
th|s may not be possible because the extensions may 
meet a requirement that cannot be provided by standard 
languages, or by target vendor extensions. Project team 
members should familiarize themselves with these 
extensions, reprogram where possible, and develop 
alternative plans for extensions that cannot be removed. 

o ^Optimize software to shorten conversion time and ensure 
efficient code is converted. 

At some point immediately prior to a system conversion, 



software development should be frozen. This will help ensure that outputs 
on source and target systems are the same during parallel testing. 
However, the experience of many conversion managers indicates that this 
is more difficult in practice than in theory. Functional u^ers often 
require modifications at some point during the conversion, aid some 
systems cannot be frozen. Established and enforced systems change 
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PROGRAM MODIFICATION AND \ 
USER ENHANCEMENTS INTO SOFTW, 




this phase. Project team members should: 
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procedures can reduce problems of simultaneously converting software 
that is under development. Change control procedures permit 
identification of a software version configuration and a continuing record 
of all changes as they are applied to specific versions, .A version can be 
selected for conversion and the recorded changes added later. If an 
agency does not have good change control procedures in effect, the 
project manager should enlist the support of the ADP manager to 
establish antf implement change procedures prior to actual conversion. 

5;13 DOCUMENTATION 

The project manager will have to ensure that documentation is 
updated. Documentation should be brought to a current state for all 
software that is not going to be completely . redeveloped (33). For 
software documentation that is in a poor state of maintenance or is non- 
existent, the project team will have to do considerable research and 
writing. Some training may be necessary, particularly for newly assigned 
personnel or contractors, in agency documentation standards or FIPS PUB 
38 and 64. Managers will have to arrange for administrative support in 
documentation production and perform quality reviews as documentation 
is produced. It is advisable to produce documentation on automated 
equipment (e g , word processing) to facilitate revision and maintenance. 

If user documentation revision .or update is required (i.e , users 
manuals) managers will have to coordinate with functional users and 
achieve their cooperation in the documentation effort. 

5.14 HARDWARE PROCUREMENT 

The project manager must keep informed of all activities 
relating to the hardware procurement. The project manager of one 
agency interviewed did not stay abreast of hardware procurement 
activities, and was surprised when target hardware^ was switched midway 
through the conversion effort. This forced abrupt, disruptive changes in 
planning and conversion preparation. 

5.15 USER AND TOP MANAGEMENT INVOLVEMENT 

As in all other phases, functional users should be involved 
throughout conversion preparation. Users have to keep the project team 
informed of any new functional requirements that impact on software to 
be converted, particularly those that occur from outside the agency. 
User's cooperation is also needed in modifying programs, freezing the 
software, and in obtaining documentation. 
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5.16 TRACKING PROGRESS > . 

The tracking mechanism, developed during the conversion 
planning phase is implemented during this phase. After assignments are 
disseminated, management must track the progress made by the project 
team as it prepares for conversion. 

At the projeqt management level all preparation activities 
will be tracked in detaiL The project manager must have immediate 
access to information on a daily basis concerning progress in: 

> o Program modification, 

o Program preparation, 

o Docu mentation, 

o Test data development, 

o Facilities - staff and conversion, 

o Equipment installation, 

o Software conversion contract, 

o Automated tools development 
l * 

The project manager cannot develop the project details alone. 
The project team leaders will assist in compiling and reporting on assigned 
project responsibilities (e.g., specific program modifications, 
documentation, etc.). Project status should be displayed on visual 
tracking aids selected for use. Bar charts are commonly used since they 
can display the status of all project activities and whether objective end- 
dates have been reached. Regularly-scheduled project team meetings (at 
least to the team leader level) are recommended, no less than on a weekly 
basis, to allow team members to surface potential problems and to keep 

the entire team apprised of progress. 
^* 

A t levels above the pro jec t manager, pro jec t status 
information should be summarized and regularly reported no less than on a 
monthly basis. Graphics (e.g., bar charts) displaying status of major 
preparation activities are equally useful in reporting project status to 
agency, executives as the more detailed charts are to the project manager. 
Scheduled project status briefings, maintained since the project initiation 
phase will continue and assist in keeping top management informed. 
Exception reports of significant problems, beyond the capability of the 
project manager to resolve, should be immediately provided. 

5.17 DEALING WITH UNFORESEEN PROBLEMS 

Unanticipated problems begin to surface during this phase. As 
problems are identified, they must be addressed. This is a key 
management issue. Postponement of problem-solving, no matter how 
minor the problems appear, may result in having to cope with larger, 
compounded problems during actual conversion. 
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Compion problems -that may arise during conversion 
preparation can be associated with the following list. Comments are 
offered on how the occasion of these issues.may be reduced or avoided. 

o Unexpected management decisions 

Budget modifications J 
Change in target njachine 
Schedule change forced on project management 

Comment: Continuing coordination with agency staff 
members and regular executive level project status 
briefings may provide advance information to plan 
and execute schedule changes. 

o Project team 

Personnel losses 

Poor personnel morale 

Skills don't meet expectations 

Personnel cannot be dedicated to project , 

Comment: ^Regular team briefings can improve morale. Quick 
reaction task order contracts can be" executed to 
acquire additional staff and skills needed. 

#ainj 

Inadequate training 
Poor attendance ' 

Conversion environment changes (target hardware 
or software is changed) 

Comment:] Training plans should have provisions for remedial 
training and additional classes. Eaqh absence 
should be challenged. Training schedules published 
well in advance reduce conflicts with leaves, etc. 

Contractual assistance 

Delays in preparing RFP package 
- No vendor bids 

Vendors cannot meet requirements of RFP 
Poor customer/contractor communications 

Comment: Accumulate RFP input in looseleaf forrp as it is 
developed in the requirements phase. This eases 
RFP preparation. Advertise well in advance an 
intent to issue an RFP and what the scope of work 
will be. On large projects insist on a full-time 
contractor project manager and have the COTR on 
the project management team. 
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o Automated tools 



No commercial tool available to meet agency 

requirements 

No vendor bids 

Delays in development in-house % 
Tools inefficient and/or inaccurate 

Comment: Assessment of automated tool requirements early 
in the requirements phase should preclude this 
issue 

o Project team facilities 

- Oefcys m e^JL, . - offloe 

furniture, telephones, modems, terminals, etc. 
Facilities are unavailable 
Delays in moving personnel 

Comment: Identify requirements early; obtain budget. 

o Conversion facilities 

Low priority given to project team personnel 
Facilities are inadequate or inconvenient 
Data communication problems 
, Unreliable hardware 

Comment: Maintain ongoing coordination with hardware staff. 

Anticipate problems early and explain 
ramifications at exeoutive level project reviews. 
^ Identify backup hardware and communications in 

contingency planning. 

o Test data 

^Developed test data is inadequate 
Delays in developing test data 

Comment: Solicit early user input in developing test data. 

Stress continuous agency maintenance of test data 
packages. 

o Program modification 

Users continue to enhance their programs, or re- 
quest enhancements 

Modification more difficult than anticipated 
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omment: Established , change control procedures? good 
documentation, and use of standard la&uages, and 
restricted use of vendor unique utilities during 
normal software operations should ease problems in 
this area. ■* 

■ " * 
o Documentation 

Additional documentation not available v 
Users do not cooperate * 
Development t or modification of documentation 
more difficult than anticipated . : > 

Comment: Establish $nd enforce documentation standards at 
V all times. . 

o Hardware procurement ' 

-\ Target, hardware change^ 

-f Delays in obtaining target hardware 

Comment: Continued and close coordination with hardware 
acquisition sts^jff-tsya must. \ 

o User involvement 

Users dp not cooperate: additional enhancements, 

modifications requested 

Users fail to provide documentation 

Users react negatively to freezing of software , 

Comment: Maintain regular reporting to top agency officials 
to gain their support and cooperation. Continue 
user interface. Involve users in project planning. 



Tracking progress 



Project team members fail to maintain records 
Project team .members fail to use reporting- 
hierarchy 

Tracking mechanism does not adequately track 
progress 

Project management fails - to use tracking 
mechanism adequately 
Costs not tracked 

* ■ 

Comment: Assign reporting responsibilities; review plans and 
tracking for flexibility and ease of use. Plans 
should be "loosel^af" in nature. Rely on visual 
tracking aids. 
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5.18 CONVERSION PREPARATION MANAGEMENT DECISIONS 

At the conclusion of the preparation phase, agericy executive 
approval will be given to proceed with conversion activities. In an actual 
conversion environment conversion will copvmenee before all preparation 
activities are completed. The actual conversion decision will be based on 
a determination that conversion Can commence with minimum disruption- 
due to uncompleted preparations 

5.19 ECONOMIC CONSIDERATIONS . 

Preparation for conversion may * require large, one-time 
expenditures to activate the software conversion plans. As a result, cost 
elements other than personnel may become significant. These include 
one-time expenses for the purchase of conversion tools, A DP equipment, 
and office furniture and fixtures to Accommodate additional conversion 
team resources (elg., contractors). Renting* these items may reduce the 
magnitude of these costs; however, certain > nonrecurring expenses for 
freight, installation and site preparation may still occur. Personnel costs 
and' related occupancy costs will increase during this phase aS the project 
team is assembled. Items such as moving expenses, new hire expenses, 
and office space renovation expenses should not be overlooked. 

The software, conversion life cycle cost . information should 
continue to be defined at the same level of*detail used during the previous 
phase. The cost information should be updated as actual expanses are 
incurred. Cost estimates prepared for thfe conversion phase should be to 
reflect the actual expenses of the conversion team assembled during this 
phase, and defined to incorporate any changes in project scope or 

schedules. . # " £ ' * ' ': 

' " ■ . • » *■ 

The primary use of the software conversion cost information 
^during this' phase is the comparison of actual expenses to cost estimates. 
Significant cost variations identified should be reported to top manage- 
ment for early resolution of potential, budgetary problems. Equipment, 
.facilities and conversion tool acquisitions should be evaluated using the 
total project cost of the conversion effort to determine the lowest cost 
/.alternative. ^Quring. this phase min6f adjustments in the decision plans 
may bk made. These .adjustments should also bei evaluated on the full cost 
impact of egfh alternative to assure the cost-effectiveness of any 
changes. °" .■■ t •: \ <\ 

Communication;. with^m^ timers during this phase 
should include cost considerations, ^ 

budgets, and evaluation of the continued cost-effectiveness of the 

proposed conversion effort. : • ; • - " * 
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CONVERSION PREPARATION MANAGEMENT CHECKLBT 

o * . ■ Conversion preparation budget adequate and approved 
o Costs being tracked 



o External impacts affecting preparation and conversion 
assessed 

Conversion project budget changes 
/ - Target hardware changes 

- Other 

o Project team reorganized for conversion preparation 
o Staffing schemes prepared 
o Training plans in effect 
o Software conversion RFP 

«W i 

Prepared 
Issued 
Negotiated 

Contractor seleK^teSK 

Contractor/protect management coordination 

o Automated tools acquired • 

Contractor developed 
In-house develope4_3 

o Staff trained in tool use 

o Conversion project team 

Notified 

- Briefed 
Responsibilities assigned 
Assembled and located 
Trained 

o Conversion facilities obtained 

Computer support 
Terminals 
^ Team informed of procedures 



!, o X 
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Test data and files available and tested 

Information system user input 
Software development frozen (if possible) 
Change control procedures in effect 
Programs modified as required prior to conversion 
Documentation completed 



Continuous and ongoing coordination and reporting with 



Information system users 
Hardware staff 

Plan tracking in effect 

Contingency plans reviewed for effectiveness, remedial 
^action taken 

Costs being tracked 

Cost estimates refined for future use 
Extraordinary costs reported to agency executives 

Conversion budget and preparations reviewed 

* Agency decision to convert 



Top management 
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SECTION 6 
THE CONVERSION PHASE 

During the conversion phafe the adequacy of planning, 
organization, and project management is revealed. The conversion phase 
also provides the opportunity to develop a software posture which will 
directly affect the success of any future conversions. 

6.1 OBJECTIVE 

The objective of the conversion phase is to complete the 
conversion as effectively as possible in the time provided, and within 
authorized budget limitations. While the objective is simply stated, the 
decisions, organization, and activities that relate to attaining this 
objective are complex and will require continuing and involved project 
management attention throughout the effort 

6.2 CONVERSION PHASE ACTIVITIES 

Figure 6-1 illustrates the major activities that occur during 
conversion. These are: 



o Team management, organization and staffing, 

o External interface and coordination, 

o Training, 

o/ Security considerations, 

b Software conversion, 

o Unit and systems testing, 

o Parallel testing and crossover, 

o Documentation. 



These activities will be discussed in subsequent portions of this section. 
The purpose of the discussion is not to provide managers minute, technical 
details associated with the various functions, e.g., software testing. Many 
technical references exist to provide this information if the experience is 
lacking in the project management or project team staffs. Rather, the 
intention is to provide managers an understanding of the functional 
relationships and the management considerations that apply to preclude or 
reduce problems during conversion and achieve the goal of an etticient 
and effective software conversion. 
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MANAGING CONVERSION TEAM 
COMPOSITION AND ASSIGNMENTS 

EXTERNAL INTERFACE & COORDINATION 

TRAINING I" 

SECURITY CONSIDERATIONS 

SOFTWARE CONVERSION 

SYSTEMS TESTING 

PARALLEL TESTING - UNIT TESTING 
DOCUMENTATION 

CONVERSION TERMINATION DECISION 
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MANAGEMENT DECISION ▼ 





CONVERSION PHASE ACTIVITIES 
Figure 6-1 

SYSTEMS TESTING - UNIT TESTING 
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6.3 MANAGEMENT, ORGANIZATION AND STAFFING 

Managing the skill mix and composition of the project team^, 
will be the biggest management challenge during the conversion phased 
There are multidimensional variables of skills, numbers of personnel, and 
time requirements. See Figure 6-2. 

6.3.1 TEAM COMPOSITION 

During the software conversion phase the project team will be 
composed of analysts and programmers augmented or assisted by systems 
programmers, training personnel, system operators, security personnel and 
information systems users. The skill mix is usualiyymade up of in-house 
personnel as well as consultants and contractors in levels of effort 
established during the requirements phase and applied according to 
conversion plans and schedules. 

Initially the project team consists primarily of analysts and 
programmers. As unit testing is implemented, systems operators and 
programmers will assist. A * v 

Midway through the conversion, information systems users will 
be assisting in system and ihitial parallel testing. Security personnel and 
information systems users will be assisting in software verification and 
validating achievement of security and privacy software requirements. 
Input from' data entry personnel, tape and disk libraries and input/output 
staff members will permit the project manager to develop efficient 
procedures during parallel testing and refine user and operator manuals. 

In the later stages of the conversion, as applications on the 
new system complete parallel testing and are accepted by users, the need 
for analysts and programmers converting code diminishes. Project team 
activities are primarily associated with parallel testing, software security 
certification, user acceptance and documentation. As people are no 
longer required in conversion activities, they revert back to normal 
duties. 

6.3.2 PROJECT TEAM ASSIGNMENTS 

Assignments and schedules for the conversion project team 
will have been issued during conversion preparations. However, new staff 
members, including contractors, will most likely be required to replace 
personnel losses or applied to resolve unexpected problems as a result of 
contingency planning. Providing these new additions written instructions 
on their project duties, responsibilities and reporting procedures will 
facilitate their integration into the project effort 
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SOFTWARE CONVERSION TEAM SKILLS AND NUMBERS OVER TIME 
Figure 6-2 



128 



6,3.3 



PROJECT TEAM INTERNAL INTERFACE 



During conversion, project meetings are particularly important 
to keep the entire team appraised of status. On large conversions the 
total staff involvement at any one time can be 30-40 personnel Team 
meetings of this size are impractical on a day-to-day basis. Periodically 
(e.g., on a weekly basis) the team should be apprised of progress or status. 
The project manager should hold more frequent meetings, probably daily, 
with task leaders to coordinate^jpnversion activities. 

The press of conversion activities will create tendencies to 
cancel or postpone meetings with the team or task leaders. This should be 
avoided. Besides keeping the project staff informed of status, meetings 
assist in developing a team spirit and sense of belonging to an 
organization in an otherwise ad hoc assembled group of personnel Most 
importantly, since management commonly assigns high quality talent to 
conversion team duties, meetings can focus considerable talent and 
experience on means to resolve problems that may arise. 

Conversion team leaders and designated specialists working on 
specific conversion ,tasks should be inputting' status to tracking 
mechanisms established for project control There will be a tendency for 
m members to delay this input due to the press of business. Project 
managers wilj have recurring needs for status information quickly ii\order 
to respond to top management requests or to respond to inquiries 
originating outside the agency (e.g., GSA). Project managers should 
therefore monitor the degree of currency of project status information 
and discipline or revise the tracking procedures if information currency 
slips. 

- Graphics, such as bar charts, should be used at the team level 
since they visually aid the project manager and the team in determining 
status. Conversion task leaders and other specialists (e.g., security) also 
will be inputting status and historical information into a history log. This 
log should be in looseleaf form but organized in some fashion which will 
support the post conversion analyses. The format described in Section 7 
for the analysis report is suggested. In addition to its historical 
significance, this log will be useful to newly-assigned team members in 
gaining an overview and understanding of project objectives and status. 

6.4 EXTERNAL INTERFACE AND COORDINATION 

During conversion regular and continuous interface is required 
with agency executives, functional information systems usees, hardware 
operations personnel and any contractors employed for software 
conversion. 

^ " : 
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6.4.1 AGENCY EXECUTIVES 



Regular project briefings and other status reporting 
mechanisms, established and ongoing from project initiation, are critical 
during the conversion phase. Although contingency and other planning 
should have precluded many problems arising during the conversion phase, 
no conversion will be 100% devoid of problems. Significant, unforeseen 
problems should be expected due to influences outside the control of the 
agency, ADP or project manager. Prime examples which have affected 
Federal conversions include budget cuts and hiring freezes. If 
contingency planning has not provided the project manager the flexibility 
to deal with these problems, support of top management will be required. 

6.4.2 INFORMATION SYSTEMS USERS 

Close and continuous interface will be required with functional 
information system users during conversion. Their support to conversion 
efforts is critical during this phase. 

Information systems users will assist the project team in 
system, and parallel testing. Additionally, if security or privacy features 
have b$an engineered into software, users will have to assist in security 
verification and software accreditation procedures. Project managers can 
expect that busy users will experience some inconvenience as a result of 
conversion activities. Their continuing support will be directly related to 
rapport established prior to actual conversion. 

User interface is most important in freezing new software 
developments during conversion. Frozen software reduces many problems 
for the project manager.' User and top maiygment support in freezing 
development will have been achieved during prior conversion phases. 
However, since the time of actual conversion can be quite lengthy, 
extending over a year in large conversions, project managers can expect 
impatience and some support to wane for postponing new enhancements. 
Attention to developing conversion priorities and schedules, approved by 
users during the planning phase and adherence tQ these schedules during 
conversion will build confidence among users that their inconvenience in 
obtaining mew enhancements will bp minimal If new enhancements 
cannot be avoided, change control procedures can reduce the trauma of 
converting dynamic systems and programs. 

6.4.3 HARDWARE AND OPERATIONS STAFF INTERFACE 

Considerable support will be required from the operations 
staff particularly during testing. Although testing can be planned and 
scheduled, actual testing will require many schedule modifications as 
software systems ate debugged. These schedule changes will 
inconvenience the operations staff. Project managers should encourage 
participation of operations staff members at project meetings to promote 
operations staff cooperation and encourage their input on day to day 
scheduling adjustments. 
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6.4.4 



CONTRACTOR INTERFACE 



Planning for conversion with large contractor software 
conversion efforts should have provided a COTR on the project managers 
staff and a contractor project officer. If this lias been accomplished, the 
day to day interface necessary to keep contractual efforts on track with 
in-house conversion actions will be facilitated. 

6.5 TRAINING 

Most of the training for conversion was accomplished ip the 
previous phase, conversion preparation. Nevertheless some training will 
be required in the conversion phase. 

If newly assigned personnel are applied to the conversion team 
to replace unexpected losses, they will have to be trained in their duties. 
Additionally, there will be ongoing, ad hoc training requirements to 
operators, data librarians and data entry personnel as operating 
procedures are refined during testing. This training is normally 
accomplished by members of the project team. Project managers should 
ensure that the necessary procedures and documentation (e.g., operations 
manuals) are developed and used in conjunction with this training* 

Information systems users normally do not require extensive 
training unless new functional changes are included in the converted 
software. Some user training may be required when users assist in 
systems testing. During parallel testing user* will have to be trained to 
the extent that they can differentiate between and compare the source 
and target hardware production runs. 

6.6 SECURITY CONSIDERATIONS 

The project manager, working in conjunction with the agency 
information System security official and the information systems users 
will ensure thatthe design reviews are conducted during systeims testing 
and that sensitive systems are carefully monitored for security during 
parallel testing. In accordance .with OMB Circular A -71, the sensitive 
information systems will require certification at the completion of 
systems testing by the information systems security officer or agency 
official designated to certify that the systems meet the documented and 
approved system security specifications, meet all applicable Federal, 
policies, regulations and standards, and that test results demonstrate that 
the security provisions are adequate. 

6.7 THE SOFTWARE CONVERStON 

/ \ Software will be converted in-house, by contractor, or a 
combination of the two, using schedules and work packages developed 
duriV planning and preparation activities. 
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6.7.1 IN-HOUSE CONVERSION 

The first source programs to be converted should be the most 
complex or those that have been frequently modified. Complex programs 
force project team members to become thoroughly familiar with the new 
software If there are going to be software problems which could result in 
serious slippage, management is provided an early awareness of this 
condition and can apply remedial actions. Frequently-modified programs 
are the most complex as a result of the modifications. They are also 
normally associated with information systems of high user interest 
Giving these priority, converting * them first, and placing them in an 
operational mode avoids 'user pressures to incorporate new enhancements 
during conversion. 

If new enhancements cannot be avoided, one method of 
minimizing the effect of modification during . the conversion is to 
implement change cohtrbl procedures which carefully record all changes. 
Duplicate work packages, go the the project te^am and the other to the 
maintenance program me r(s). The maintenance ptogrammers continue to 
make changes as the frozen programs are converted. Changes to the 
converted program are added later (23). 

6.7.2 APPROACHES 

The conversion approaches taken by the project team are team 
conversion, individual conversion or a combination. The project team 
members will employ the previously-decided techniques of manually 
converting code on a line-for-line basis, reprogramming, redesign, the use 
of automated tools, or a combination of the four methods. Selection of 
the approach will be an agency management decision based upon available 
personnel resources, skills and experience, time available, and desired 
performance of the converted programs. 

r- 

6.7.2.1 Team Conversion 

With team conversion, each membfer of the team is assigned 
either Control Stream Language (CSL), data files, or source programs. 
One person or group of people is in charge of converting all CSL, another 
handles all data files, and 'a third converts all source programs. The 
teams differ in size as dictated by the conversion workload. . Also, the 
skills required of the team members would differ. The CSL and data file 
teams need not be trained in application program languages, e.g,, COBOL, 
Assembly Language, FORTRAN, etc. The advantage of this approach is 
the facility in developing conversion staff skills. Each team has only to 
become experienced in specific rather thaji broad software skill areas. 
The expertise in each area will be more quickly acquired and applied. 
Each team can develop expertise in the other areas later, as tirrie permits. 
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6.7.2.2 Individual Approach 



With the individual approach, each person converts all aspects 
of the system in his/her realm of responsibility: CSL, data files, and 
source programs. For shared data files, conversion Responsibility should 
be assigned to one' person. The advantage of this approach is that 
individuals become familiar with thfe total requirements of the individual 
systems. The responsible person can often anticipate and resolve some 
problems which might arise based on this insight. The disadvantage of 
this approach is that it fakes longer to deyelop all the skills associated 
with^system conversion rather than one particular area of expertise, e.g., 



6.7.2.3 Modified Approach 

The modified approach is a combination of the two. An 
example would be team conversions of CSL and data files. Application 
programs would be converted by a functionally-knowledgeable project 
team member. This approach permits tailoring existing resources and 
skills to agency conversion needs. 

6.7.3 CONTRACTOR CONVERSION 

With contractor conversion of the so^fce cbde, the project 
manager is less concerned with the approach. The management concerns, 
instead, are contract management and issues associated with timely 
delivery, quality and documentation of software. 

6.7.4 QUALITY 

Converted software should be closely reviewed for quality. 
The pressures on personnel during conversion to meet the -conversion 
schedule, may cause project team members to retain unnecessary or 
unoptimized code (48). The conversion phase provides the opportunity to 
develop well engineered source programs based on modern techniques of 
software engineering (39, 42, 43). It is also an opportunity to design i out- 
old routines Which require operator intervention but, due to technical 
evolution of hardware, are not applicable on, the new system. It is 
particularly important for contractually-converted software to be , 
examined for quality and performance to ensure converted systems 
execute in accep table run times. The project manager should regularly ^ 
schedule and conduct structured walkthroughs of all conversion projects- 
and similarly examine contractually-converted software. 

,6.8 UNIT AND SYSTEMS TESTING 's , 

Initial testing is normally accomplished ' jn/ two 
steps: individual application program and file (unit) testing^'attd ' system 
testing (see Figure 6-3). Managers will have to schedule or arrange 
supplies and paper stock, rp&chine time, operators, test data, system 
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programmers, and possibly, during systems testing, user involvement. 
Test criteria should be established, beforehand. :THe test criteria should- 
includeoperformance factors that relate to the; desired level of quality, be 
used to evaluate individual or contractor performance, and ensure that 
; cost-effective results are being obtained. 

6.8.1 UNIT TESTING ' • . * 

Individual data files should be tested to 'ensure that they have 
been 100 percent converted. Individual application programs require 
testing- to ensure that the: code is executed The. adequacy, of this testing 
depends upon the quality of test data. The ultimate ^objective is r00 
percent testing of code execution. While this objMtive : ''is v r.pa&tically 
unattainable, the project manager is encouraged to continually refrhV fest 
data towards achieving that objective. ■ . 

^6.8.2 SYSTEMS TESTING ' . - • / A !r 

After unit testing pf programs and files are completed they 
are subjected to systems testing.- The purpose of this testing is'fo ensure 
that the systems operate adequately on the tarjget hardware. .Systems 
test data consist of representative production runs with' appropriate 
performance consideration taken mto account. AU systems document- 
ation should be written in an acceptable draft state by the e^d of systems 
testing. a Systems testing will involve' information "systems user 
participation to verify r the acceptability of new input and output 
procedures. ■ u 



6.8.3 TESTING PROBLEMS V 

6.8.3.1 Assembly Language and Utilities 



Rroject managers shoulm be prepared to handle serious 
problems during systems testing if ffle agency converts from Assembly 
Language on a saturated machine brf has made extensive use of vendor 
unique utilities. Unacceptable run times can occurJwjiich require redesign 
or extensive rebrogramming. * v 

6.8.3.2 TeWng Shortcuts & 

Q ua 4fc test data is extrent^J^ important and difficult to 
develop an dj^w||in (48). Managers sh0tild resist test data shortcuts as 
an exped^elTtg^^oiding the need to develop different test packages, 
however^; J^H* . : i 





__-^Vnit test data should not be used 'for systems testing. JJnit 
test (M^p/designed to exercise the converted code. The* systems test 
-^taf .arrived from, and represents typical production runs, the test 
".dat^ construction is different The projept Manager should also resist 
S?de for systems integration testing that has not completely 



' fulfilled unit code execution tests. The manager should likewise, not out 
cb^e in'td ia parallel testing mode that . has not been fully, tested; and 
drugged' during systems testing* Shortcut^ fii*f^t^^.^;pt^ii^..ot 
conversion only defer problems M the tateir^^^^]^1«^.^wrsi^ 
• Testing problems need to be Jejolved as early AS' possible to' preclude an 
-unmanageable situation in which cumulative testing problems have to be 
addressed and solved late in trie conversion "phase* . Unit and systems 
testing reduce to a minimum" software problems; that, will come to the 
attention of the functional user during paraUei;;t^^.-. ; /A',low incidence • 
of errors in production runs inspires user confidence and support. 

6.8.3.3 Production Interference ■: 

Because it is difficult to forecast exactly, the machine time 
and other resources required for actual testing, ^an'^ge ment will have- to 
maintain close coordination with operations personnel: and users to gain 
their; support and cooperation to alleviate unexpected; Resting problems 
that place an unplanned burden on normal operations. • v. ■ ■ 



ft* PARALLEL TESTING AND CROSSOVER 



During parallel testing the project manager is going to be 
concerned with running the old and new systems in a parallel production 
mode to ensure that conversion has been accomplished , v 

A management problem exists for those applications that are 
infrequently processed (e.g, fiscal year end summaries). It may be 
impractical to continue parallel testing long enough to compare all long 
term applications. The objective will be to achieve, user's confidence, 
crossover to the new system, *andv remove the old hardware in order to 
. reduce costs associated vyitti parallel testing or back-up processing. When 
systems have been are undergoing parallel" testing, a firm 
Completion date must 't>e established to force an end ;to the conversion 
project. . 

-As systems complete parallel testing it is important that Users 
formally acknowledge acceptance. This provides a ba$fc of understanding 
between the ^rs and the project manager that conversion of thp .^sterns, 
has been successful. . v ' - , ^ * 

. : ■ " • - 

16.10 DOCUMENTATION > v ' 

^ The project manager should demand software documentation 
in accordance with ''agency or FIPS standards. Managers should be 
especially cautious regarding documentation associated with that 
Software converted by a contractor (42). The normal form for delivery of 
.V, contractually-converted software is in an undocumented state. Managers 
should anticipate that even if contracts require documentation, the 
. Contractor may be unfamiliar with documentation standards, may have 
^ underestimated resources and may try to avoid ?r modify contractual 
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6.11 CONVERSION MANAGEMENT DECISIONS 



The conversion phase is over when the last system completes 
parallel testing and documentation is completed. Upon assurance that 
,/users have accepted the^ converted information systems, agency 
executive^ will approve project management recommendations to 
implement post-conversion activities to restructure the software 
conversion project Jteam to a normal operational mode, close out software 
conversion contracts, vacate or release any conversion facilities and 
equipment no longer required, 'and to conduct a post-conversion analysis 
of the^conversion project 

It is recommended that 'these decisions ■ be based on 
recommendations presented as part of a formal briefing to top agency 
managers and informatipn system- users. This will lend assurance that 
conversion has been successfully executed and keep management informed 
of the conversion activities that are required during the post-conversion 
phase. 

6.12 ECONOMIC CONSIDERATIONS 

During the conversion phase the major elements of cost will be 
personn$F-related. Hardware and telecommunications expenses may 
become significant during this phase, for file and program conversion and 
testing. These expenses friay be reflected by direct^hardware rental costs' 
of indirect time-sharing charges^ If the software conversion effort uses 
1 existing ADP resources, the costs of these resources should be identified 
jandf "allocated to the conversion effort on a full cost-basis. The cost of 
fusing contractors should be estimated and recorded according to the 
•* v */ detailed cost structure approach presented in Appendix C. In this manner, 
V contractor costs should be detailed b^cost,, element; i.e., personnel, 
facilities, hardware, overhead, profit, ^tjp/ for^ach conversion activity or 
function, and not given as a lump sum : £pntracjt Service expense* t With this 
cost breakdown, the technical evaluation of^o^tractor's performance will 
be possible. ; ^| f 

Actual cost performance should be collected and^recorded in 
the cost structure for use in post-conversion audits. • v 

The use of the software conversion cost information is mainly 
lib the tracking of project costs and the comparison of actual cost to cost 
estimates to identify significant cost variations. Communications with 
users and top management should include cost information such as 
expenses to-date, budget projections, and an evaluation of the cost- 
effectiveness of the project Minor changes in'ptoject schedules and the 
allocation of in-house or contractor resources to specific tasks should be 
performed with consideration of cost impacts. This project refinement 
aqtivity should include an assessment of each alternative on thetfull cost 
of conversion in order to address the lowest total overall cost 



CONVERSION PHASE MANAGEMENT CHECKLET 

o Conversion team * ' 

Located in facilities 
Requisite skills and experience available 
Team members aware of schedules, duties and 
responsibilities 

**• * • ■ * ■ 

: 'x£u Interface continuing with 

Agency executives 
Information systems users 
Hardware operations staff 
Contractor projectofficer 

o Project, status being tracked 

o Project status r current 

•fo- Project reports current 

At project level 

At agency executive leviel 

o Training being accomplished 

New hires on project team 

Ad hoc to users, operators, etc. 

o Security 

Features implemented in software; verified 
Monitored by information system security officer; 
• ' users 

Software certified by information system security 
officer, IAW OMB Circular A-71 
Most complex software being converted fi^st 
Change control procedures established for 
conversion of software with new enhancements 
Conversion team members following established 
security procedures 

o "Contract being monitored; quality of software and 
documentation assured 

o Unit and systems test data separate j 

o Files 100% converted 
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o Software converted to level of acceptable code 
execution 

o Users participating in systems and parallel testing 

o Close interface with hardware operations staff during 
testing 

o Users formally accepting systems at completion of 
parallel testing 

o Firm parallel testing end date established to force 
project end 

o Agency executives and users approve end of the 
conversion phase 

o Agency executives approve post conversion phase 
activities 

Settling staff into normal software operations 

Close-out contract / 

Post conversion analyse? and assessment 
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SECTION 7 
THE POST-CONVERSION PHASE 



Post-conversion is the phase of a software conversion life 
cycte between actual conversions. It extends for an indeterminate but" 
coipfcerable period of time, generally 2 to 5 years, depending upon the 
frequency of Hardware replacement. This phase provides the best 
opportunities to learn from fresh conversion experiences and to initiate 
actions which will improve the utility and effectiveness of an agency's 
software and concomitantly facilitate future software conversions. 

Additionally the true costs of conversion are most apparent in 
this phare if costs have been tracked. Differences between estimated and 
actual costs can be identified and evaluated. These evaluations can then 
lead to better cost estimating in future conversions. 

7.1 OBJECTIVES 

There are two objectives in the post-conversion phase: 

o . Reestablish the agency software organization in at 
normal operating environment. The associated activities 
are to complete any functions from the software 
conversion phase which remain undone (e.g., 
documentation, completion of parallel testing); settle 
the software staff in a normal organizational structure; 
and begin norn\al software maintenance and development 
actions. » 

o Develop a better agency posture for future software 
conversions. The agency should conduct a post- 
conversion assessment of the conversion experience; 
begin planning for the next conversion; and initiate 
actions which will cause the next conversion to be more 
effective and efficient. 

7.2 POST-CONVERSION ACTIVITIES 

Figure 7-1 illustrates the m^ijor activities that occur during 
the post-conversion phase. Many of these activities are closely related 
and have much overlap, particularly those that pertain to the post- 
conversion analysis and assessment, planning, and conversion improvement 
techniques. These activities provide the framework for subsequent 
discussions in this sectW/ which provide an understianding of the post- 
conversion management issues. This general understanding will assist 
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managers in identifying other post-conversion functions that pertain to 
their particular agency software conversion environment and form a base 
on which to build or implement actual post-conversion plans and actions 
to improve future conversions. 

Post-conversion activities can be generally grouped into three 

categories: 

o Conversion Termination/Transition Activities 

These are transition activities between a conversion 
' environment and a normal software maintenance and 
development environment. Typical activities include 
finishing parallel testing, completing documentation, 
closing out software conversion contracts, disbanding the 
project team, and settling the agency software staff into 
a normal software organization (e.g., systems 
programming, maintenance programming, developmental 
programming). 

o Post-Conversion Analysis and Assessment Activities 

These activities involve conduct of a thorough review 
and analysis of the entire conversion experience and 
preparation of a formal after-action report This 
• document will provide managers a historical perspective 
of the conversion, and assist in understanding future 
conversions and ways to avoid repetitious mistakes. It 
also provides a reference on which to base the closely- 
related activities of future conversion planning and 
implementing actions to improve future conversions. 

o Future Conversion Planning and Conversion Enhance- 
ment Techniques 

Early initiation of future conversion planning reinforces 
the recent conversion lessons learned and significantly 
improves management's ability to comprehend all the 
issues of future conversion. Management can also 
implement and enforce many techniques and procedures 
which will improve the quality of the agency software 
and, at the same time increase software portability. 
These methods include use of modern software 
engineering techniques of structured design and 
programming, maintaining * current documentation, 
avoiding the use of non-standard programming languages 
and vendor unique utilities, maintaining high quality test 
data and files, and maintaining disciplined program files 
and data bases. 
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7.3 CONVERSION TERMINATION/TRANSITION ACTIVITIES 



In a theoretical conversion, activities associated with the 
conversion phase would have been completed before the post-conversion 
phase began. In a real situation activities of one phase extend into 
another. The most significant on going functions of the conversion phase 
that are likely to extend into the post-conversion pTiase are parallel 
testing and documentation. Activities such as closing out contracts and 
disbanding the conversion team will be more transitionary. Still other 
activities such as commencing new uSer enhancements postponed until 
after conversion approach true post conversion activities. 

7.3.1 COMPLETION 'OF PARALLEL TESTING 

Software is converted on a prioritized, scheduled basis 
according to conversion plans. Thus, in the initial stages of the post- 
qonversion phase all of the soft-ware will have been converted. However, 
for those software applications converted last, some residual testing, 
particularly parallel testing, will likely still be on going. 

TJie management issue here is to strike a balance between 
continuing parallel testing to ensure that the converted software meets 
functional user requirements/ ^yjiile -at the same time, avoiding protracted 
or unduly long parallel testing arid operations. Parallel testing is costly in 
terms of dollars and staff resources. As long as parallel testing and 
operations persist, transition to a normal software environment cannot be 
accomplished. p^jNfefefore managers should closely examine parallel 
testing with a bprftihual involvement to determine ' if the seemingly 
endless details 'ofi $sr£llel testing outweigh the benefits of maintaining 
two hardware opiating environments. Project managers may have lost 
the perspective to* iriake this judgement. Upper management must be 
prepared to exercise "brtite force" decisions to terminate parallel testing. 

7.3.2 OOCUMIMTTATION 



\;' ^Softv^are^ournentation should be written concurrently while 
convetiir^g softwa^l^Howeyer, during the later stages of the software 
conygRigh pha^ j^ pumentation efforts may fall behind and extend into 
the £tet-c^i^ Also, some documentation modifications will 

be requipjj^^ modifications to converted software as a 

result jrf final' pii^llel testing. 

]\\ v. ^ may extend into the post-conversion 

phase,' ^ 1 - 0^ jj, t|o^l ; : 't Jia it v rriariag e m en t ensure completion before total 
transition ofcsp^^ a normal state. Software that is not 

documented t^iri^^^ and this creates a continuing 

source of ^pblems:j[23) . . / \ : \ \ 
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7.3.3 CLOSING OUT CONTRACTS 

If contract services have been used to convert software or to 
augment the conversion team staff, the project manager will be involved 
in contract close-out activities. If extensive contractual support was 
used, contract close-out will be significantly aided if the software 
conversion project management team has a full-time COTR to assist in 
contract functions (49). « . 

Contract monitoring should have been an ongoing function 
throughout the conversion process. During the post-conversion phase, the 
Statement Of Work (SOW) should be reviewed and compared with the 
deliverables to ensure that contractual obligations have been met. Actual 
cost performance should be compared against original estimates to 
determine contractual awards or penalties. Software deliverables should 
also be examined for quality and fully supported by documentation that is 
well written, usable and conforms to agency standards or FIPS PUB 38 
and 64. ' ' 

Contractual issues and disputes should be resolved informally 
whenever possible, or if necessary, formally through the contracting 
office. A full assessment of contractual costs and obligations should be 
conducted to assure that the agency received full benefit of services and 
to surface and resolve outstanding cost issues, thus avoiding any prolonged 
contractual disputes which would detract from normal operations. When* 
all contractual issues have been resolved, the contracting office should be 
notified, in accordance with agency procedures, to close-out the contract. 

The key management concerns are to ensure that contractual 
obligations have been fulfilled, and potential or actual problems or issues 
identified and resolved as expeditiously as possible in order to accomplish 
a speedy transition to normal software operations. 

7.3.4 DISBANDING THE PROJECT TEAM 

As parallel testing and documentation is completed, remaining 
members of the project team should be released. Those team members 
who are normally part of the agency software staff will revert to normal 
duties. Since large scale conversions frequently last in excess of one year 
the "normal" duties might be quite new. For example, personnel turnover 
might have resulted in newly-hired personnel being' assigned directly to 
the conversion team. For these people, there will have been no previous 
experience in agency day-to-day operations. They must be assisted in 
adapting to the normal environment. 

Requirements for reorganization of the agency software staff 
may also impact disbanding the project team. Agency growth or 
functional changes may have altered the" authorized staffing level or skill 
mix of the software staff. Differences in the source and target computer 
systems may also have generated a need to restructure the software staff. 
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Management problems in settling the agency software staff 
into a normal operational mode can be reduced by i n forming all 
conversion team personnel of the normal agency software organization, 
and providing current duty , descriptions, and internal operating 
instructions. Training can also be of assistance particularly if the project 
members worked only on specialized conversion tasks (e.g., only converted 
job stream language). 

7.3.5 NEW USER ENHANCEMENTS 

User information system enhancements, deferred until after 
conversion, will commence. Because of the length of some software 
conversions, some application software may have multiple change 
requirements. Information system software changes and enhancements 
should be carefully analyzed. It may be cost-effective to redesign 
systems, and to incorporate aii cnanges at once, rather than patching 
them into the old system structures. Also, if there are many 
enhancements required, priorities will have t£ be established. Priority 
assignments will require functional user involvement and top management 
decisions and support. n 

The management issues include identifying and establishing 
priorities for developing new user enhancements and determining the most 
cost-effective approach for accomplishment. Managers should also ensure 
that all software changes are accompanied by appropriate changes in 
system documentation. ■« . 

7.4 COST-TRACKING 

During the post-conversion phase, tracking conversion related 
costs as they are incurred on a day-to-day basis is important to reflect 
total conversion costs in the post-conversion analysis and assessment 

Operational cost items associated yith the post-conversion 
phase include, but are not limited to: 

o Staffing - Staff resources devoted to conversion-related/ 
actions as opposed to normal operations (e.g., costs 
associated with disbanding the project ;teanr and 
resettling the norma! software staff; training). 

o Contractual - Costs associated with closing out 
contractor support. 

o Computer /knd Facility - Costs associated with residual 
conversion functions such as completion of parallel 
testing and residual use of facilities by the project team. 
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o Administrative - Costs associated [ j; with clerical £tnd 
administrative support to the project management and 
project teams; particularly the administrative support 
associated with the post-conversion analysis and assess- : 
ment and future plan development. Documentation 
production will also incur administrative costs. 

7.5 POST-CONVERSION ANALYSIS AND ASSESSMENT 

One^xrf the most important post-conversion functions is an 
analysis of the entire software conversion experience. The time and 
resources required to conduct the analysis and assessment depend upon 
the magnitude of the software conversion project. A medium to large 
conversion project assessment might involve 2-3 people for 2-3 months. 
The analysis should be conducted by the project manager and the project 
management team with input splicited from parties that hafl an important 
interest or role in the software conversion (e.g., the contractor, project 
team, hardware acquisition staff, involved functional users). The most 
important sources should be conversion history logs maintained on an 
ongQing basis during the software conversion and the knowledge and 
experience of the project management team that remained intact during 
the entire conversion experience. 

It is important that the post-conversion be conducted in a 
positive manner. It should not simply be a list of problems or 
shortcomings encountered during conversion. The assessment should 
describe the entire process and identify those procedures that were 
satisfactory and effective as well as those that were Jess than 
satisfactory. It should offer future software 4 conversion managers 
suggestions and recommendations to improve their conversion efforts. 
The assessment should identify how the agency can plan, now, for future 
conversions; ongoing software practices and procedures to improve future 
conversions; and other actions (e.g., policy change recommendations ) 
which may be required. 

7.5.1 POST ANALYSIS REPORT 

A post-conversion analysis report should be produced as a 
formal document. It serves four important agency purposes. 

o Historical Reference 

The report .provides a historical reference for agency 
personnel to use in future software conversions. The 
identification of problem areas and solutions should 
provide future software conversion managers insight and 
enable them to better manage and execute a software 
conversion. 

i 
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o Conversion Costs 



■ The report displays actual conversion costs. If the 
■ software conversion cost structure, detailed in Appendix 

■ C, has been used throughout the project, the report will 

>-l ^ ij reflect all costs including those frequently overlooked or 
■r disregarded by managers. For example, the costs of 

... assigned staff personnel, particularly those involved in 
conversion .part-time, are -frequently overlooked; 
v > 7 conversion costs related to parallel testing, particularly 
"V" ; with government-owned machines eyre not fully 

considered; the full extent of training costs (e.g., 
training time) tends to Jdq underestimated. 

o Basis for Software Conversion Planning 

Planning .for spftw are conversion should be an ongoing 
activity and not solely relegated to £ planning phase 
immediately preceding t an actual conversion. Continued 
planning 1 (for the eventual software conversion can 
shorten the planning time span when a conversion 
decision is made, provide : \ more detailed, arid 
, comprehensive plans, and improve the overall ebhversion 
process. The report provides insight on how to structure 
the planning. 

o > Identify Ongoing Actions or Procedures to* Improve 
Conversion 

There are many actions and procedures managers can 
implement and enforce which will improve the posture of 
an agency to conduct a cost-effective cqhversioru The 
report, by identifying these actioh? and their 
importance, assists agency personnel in understanding 
the need for these procedures and. encourages 
implementation* 

7.5.2 ANALYSIS CONSIDERATIONS 

Elements to be considered in the post-conversion assessment 
will depend upon the software environment of the particular agency. 
However, the following are generally applicable. 

o Planning 

Adequacy of feasibility study 

Adequacy of sof tware conversion study i ; > 

Impact of other studies! (e.g., A-76, A-109) 1 

Adequacy of planning time 

Sufficiency of detail - 
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Adequacy of tracking and management ^fdlldw"^ 
through <v : 

Adequacy of cost estimates 

Planning problems, their resolution and means of^ 
avoidance ; ' » -y/ 

Future planning requirements 

Staffing and Organization : 

Adequacy of project management team 

Adequacy of project team , . 

Skill mix 

Proper location of conversion staff s ' 

- • Adequacy of conversion assignments and control 

Staffing and organization problems, their 
* resolution, and me&ns of avoidance 

- Future planning requirements v ; ^ 

Use* of Contractors n , * ... , ■;' 

. V . ■ '"-i^ " V > ' • ."" :. '.^/ 

Requirements for contractors 
Their optimum employment ' 
Adequacy of the Request for Proposal r 
Adequacy of contract monitoring 
Adequacy of deliverables and services 
Pontractor problems, their resolution and means of 
avoidance 

Future planning requirements 

Software Conversion l r 

Selection, use and adequacy of automated tools and 
techniques 

- Conversion of languages y. 

- . Conversion of utilities and procedures 

Conversion problems, their resolution and means of 
avoidance 

Future planning needs 
Hardware Staff Interface 

- . Adequacy of hardware acquisition staff interface 

Adequacy of conversion support 
Conversion problems, their resolution and means of 
avoidance / 
Future planning requirements 

Facilities - 

»* 

Adequacy of facilities 

Success in single site/dual site conversion ;'\ '„* 
Facility requirements and use 
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Documentation 

Adequacy of^pre- and post-conversion documen- 
tation 

- The use of documentation 

- - Adequacy of agency documentation standards. 

- : Documentatidn problems,/ their resolution x and 
m 

Future planning requirements ' 
Test Data and Files 

Employment of test data and°f iles 
Adequacy .of test data and files 
Optimization of test data and files 

- Development responsibility for test data and files 
Test data and file problems, their resolution, and 

* means of avoidance 

Future planning requirements * . 

Training \ 

Adequacy of training * 

Timeliness of training 

How triaining was conducted ^ ; •;. 

- Training problems, their resolution and means of 
avoidance 

Future planning requirements 
Security - 

Agency specific security and privacy requirements 
Adequacy of security and privacy software 
conversion activities 

- , >^E)^eat of unresolved security or privacy software 
^ issues. ' " "' ■;■ ' ■ 

Security andprivacy problems, their resolution, 
and means of avoidance • . 
Future planning requirements 

Distributed and Remote Sites ' 

• ■ ■■■■■■■ ■■■■■ ' . * ■ ' ■ ; 

Adequacy of planning / 

Interface ' 

Adequacy of software conversion 

Specific problems,, their resolution arid means of 

avoidance ^ \ 

- Future planning requirements 
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Telecommunications 

Adequacy of telecommunications planning 
Adequacy of telecom myhjejations staff support 
Conversion-related problems, resolution, means of 
avoidance < J § . \ 

- * Future planning considerations 

.»+<■■ • '• "■ -.. 

JTop-Mffiagenfent and Functional Users 

- Their support of conversion 7 *$ 
Freezing development of.new usfer* enhancements 
Their roles and involvement in cbnversfon /"* 
High level management and* us^r cdrivjersion- 
related problems, their resolution^ gnd m*a!ns : of 
&yoitiance - ' ? 
Future planning requirements ; 

* 

Directives and Polifey ^ . "-v" 

Adequacy of directives and policy 

- Conflicts in directives and policy 
Responsibility .for directives and policy conflict 
resolution C ■ :. 
Future planning, consideration^ 

Unforeselii Problems 

Unforeseen problems, their resolution, and means 
of avoidance 

Future planning considerations 

Software Conversion Management 

* * 

^* If not othtefwiae addressed, cover shortcomings or 
i support from software conversion management that 
; affected other related projects or operations. 

tv '■ Telecommunications 

Hardware acquisitions *\ 
Hardware operations ■ 
Inform^tion'System users v( - 
. r Agency^>x r ecutives • 
. ^ Budgets an^t plans 

Costs 

- ; Actual conversion costs/By phase, function artd cost 

element . J 4 v : * 

Totril conversion costs 



Adequacy and source of funding 

- Adequacy of budgetings 
Comparison of cost* estimates >to actuals 

Adequacy of cost analyses 

Cost overrun detail and reasons 

- Conversion cost i-elated problems, theijr resolutign 
and means of avoidance - * , 

- Future planning considerations 

• • * ♦ / 

7.6 PLANNING AND INITIATING ACTIONS TO IMPROVE' 

FUTURE CONVERSIONS 

Futurp, software conversions ccfh be made more efficient aiid 
effective toroi^ft employment of a combination of planning and 
procedures 4"tfiat encourage \easily maintainable software and its 
conversion.. Sdlhe. activities can be specifically identified as pure planning 
— i.e M conversion planning input into agency ADP budget submissions- 
required by OMB Circular A-li. This is long-range planning. At the 
agency software operations level, some software conversion improvement- 
actions will be planned and implemented. This is technical planning and it 
will differ among agencies. Practices conducive to efficient software 
conversion such as disciplined documentation may be firmly established 
and on-going at one agency and require no planning/ only continued 
implementation. At another agency, however, a docu frgnta tidn standards 
policy may have to be planned and implemented, If m^Bfc^pwrsue both 
long-range and technical conversion planning, future col^^^fc will be 
much simplif ied. 

7.6.1 LONG-RANGE CONVERSION PLANNING 

Long-range planning is based on costs. The cost estimating, 
analysis and tracking experience gained , in the a recent conversion, if 
continually refined during the post conversion phase, can assist managers 
in estimating correct levels of conversion resources. If the project 
manager has been following a total cost estimating methodology as 
recommended in Appendix C, the structure can be transferred to agency 
personnel who are routinely involved in long-range planning. 

Planning full costing methodology permits an agency to 
analyze costs from different dimensions. For example, costs can be 
developed for personnel, by phase, year, o( for a total conversion project. 
Alternatively, all costs of conversion (e:g., personnel, equipment, etc.) 
can be devel6£>ed by phase or by year. This methodology will produce 
consistent cost estimates from whatever perspective they are examined 
(e.g., full costs of programmers will result in the same total if they are 
developed by year or by phase). This consistency results in significant 
advantages for an agency by precluding conflicting cost estimates and 
providing credibility to agency plans, studies and budgets. 
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*7. 6.1.1 Agency Long-Range PlaUp 

9 Office of Management and Budget Circular A-ll requires 

agencies to preparS and submit annual agency-wide ADP plans which 
support budget estimate submissions covering at least five years. Since 
federal hardware is replaced every 7-8 years and conversion time of 1-3 
years^ape incorporated in that span, software conversion planning will be 
required in the majority of agency plans. 

7£.1.F Input ToGSA 

c. t 

Genqral Services Administration CFR/ Part 101-35 also 
requires GSA be furnished a copy of the agepcy long-range plan developed 
to support budge^ submissions with supplementary information addressing: 

£r o Trends in data processing workloads, f that will or may 
saturate existing ADP systems capabilities prior to 
• ■ ' - " expiration of the anticipated systems life, 

p Opportunities to take advantage .of cost-effective 
enhancements brought about as a result of hardware 
technology and software improvements, 

o System redesign or conversion activities planned or in 
process to improve efficiency. 

This supplementary annual input to GSA illustrates the need to 
maintain continued software conversion planning based on costs. All plans 
and input will have to be addressed in terms of cost impacts. 

7.6.1.3 A-76 Studies „ " 

ADP is considered a commercial" and industrial type activity. 
OMB Circular A -7,6 requires specific evaluation of these* activities 
annually "as well as at the time of major change to determine if 
government ADP services and functions could be cost-effectively assumed 
by a contractor. Major agency conversions or hardware acquisitions are 
usually preceded by an A-76 study. Software conversion planning input 
based on full costing ijpjequired. v * 

7.6.1.4 A -109 Studies 

< * 

An agency may consider a hardware replacement a major 
systems acquisition falling under the provisions of OMB Circular A-109. 
' Software conversion planning inpttt will be required to develop the mission 
need for the system, analysis of alternatives, and selection of ,a final 
system. 1 . 
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7.6.1.5 The Next Conversion 

Ongoing, long-term planning for conversion will provide the 
details and methodology already in place to support future conversion 
feasibility studies, software conversion studies and conversion planning. 
An agency will thereby be in a position to complete a future conversion 
project in a much shorter time span than required for current projects. 

7.6.2 CONVERSION TECHNICAL PLANNING AND ACTIONS TO 

IMPROVE FUTURE CONVERSIONS 

During the post-conversion phase many actions and procedures 
can be planned or implemented by management to improve future 
conversions. These procedures should be either established agency 
practices or implementation of ongoing conversion plans. Most of these 
procedures are synonymous with disciplined software management and 
should be implemented and- enforced regardless of their role in future 
conversions. 

* 

The fallowing technical planning considerations 'that can be 
applied or enforced during ttje post-conversion phase were developed from 
analysis of software conversion case histories. Thfey all "support 
portability and efficient conversion. 

o Software Libraries and File Maintenance . Conversion 
planning and execution is often complicated by 
extraneous and outdated programs, files, and data bases 
(e.g., outdated systems, old test files). Software 
libraries and data bases require disciplined control and 
purging to ease actual conversion planning and 
execution. Such purging makes maximum effective use 
of hardware facilities on a routine basis. 

o User's Support . Rapport and understanding must be 
maintained between the data processing staff and the 
functional users. This reduces user's pressures for 
Introduction of new enhancements during conversion. 

o Top Management Support . Executive-level support is 
required during conversion to provide authority to 
software conversion managers and assist in providing 
resources to complete conversion and resolve unforeseen 
problems. The APP managers should seek some 
continuing means to give software management visibility 
during the post conversion phase. Periodic briefings, 
perhaps at six months intervals, are recommended. 

o Training . Continuous training of the data processing 
staff in good software engineering and documentation 
techniques promotes routine production of software of 
- y y high technical standards as well as portability. 

^7 
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Security . Sensitive systems require security features to 
be carefully considered and engineered into software. 
The time of actual conversion does not provide the 
optimum environment to develop security specifications 
due to conversion pressures. Security is best addressed 
systematically during the post conversion phase. Then, 
security features are already engineered into software at 
the time of conversion. 

Documentation . Adequate, current documentation, in' 
accordance with agency standards or FIPS PUB 38 or 64 
provides, at the time of actual conversion planning, 
detailed systems information needed to prioritize and 
develop schedules. It improves understanding of system 
requirements by outside personnel who assist in planning 
(e.g., contractors). Documentation facilitates the 
efforts of those actually involved in conversion duties. 

Standard Languages . Use of standard languages, by 
definition, facilitates portability or conversion of 
software. Vendors offer hardware and operating systems 
that accommodate standard languages. Conversion tools 
and techniques are available to convert standard 
languages. Programmers, analysts and consultants are 
^generally familiar with standard languages. 

Vendor Unique Utilities . Reliance on vendor unique 
utilities degrades portability and conversion. Software 
staffs should be discouraged from large-scale use of such 
utilities. 

Software Engineering . Modern techniques of structured 
software design and development, and modular 
programming facilitate conversion and ease of software 
maintenance. 

File Design . Files should be designed for ease of access 
by standard languages. DBMS should be employed so 
that they caij be supported on a variety of common 
vendor computer systems. 

a, 

Test Files and Data . Test files and data require design 
and maintenance to ensure that quality software is 
developed and implemented. This quality assurance is 
required during software maintenance as well as suring 
conversion. -y 

Optimization . Spftware under continuous modiffcatiori 
should be periodically examined .for efficiency and 
optimized as required. "^f 



132 ^54 



7.7 POST-CONVERSION MANAGEMENT DECISIONS 



There are two major management decisions. 

First, any parallel testing which continues into the post- 
conversion phase must be terminated This will halt costly conversion 
activities and lead to restructuring the conversion staff into an 
environment conducive to routine operations. 

Second, the post-conversion analysis and assessment report 
should be approved. This is the last official act of the project manager 
and concludes the conversion project. Activities continue, however, in 
planning and preparing for the next conversion. 

7.8 ECONOMIC CONSIDERATIONS 

It is important to distinguish between the identification of 
software conversion costs and the use of this cost information as it 
applies to this phase. In order to provide a standard, finite definition of 
software conversion for cost estimation purposes, the cost structure 
defined in Appendix C ends with appproval of the post-conversion analysis 
and assessment report. Costs will include significant expenditures 
associated with settling the conversion team into routine software 
operations (e.g., relocation expenses moving from temporary real estate, 
shipping terminals used only for conversion). Other software conversion 
costs which are not project-related (e.g., long term planning) incurred 
during this phase will not be estimated in the software conversion cost 
structure. 

During this phase, personnel expenses will constitute the 
majority of the total cost as manpower is expanded to perform the post- 
conversion analysis and assessment Additional cost areas that may be 
significant during this phase include relocation expenses for the 
conversion staff and freight and transportation expenses for the office 
furnishings. If equipment acquired for the conversion effort is released, a 
reasonable residual value for the equipment should be credited to the 
total software conversion cost. 

Th* use of the software conversion cost information during the 
post-conversion phase will require a review of both estimated and actual 
costs accumulated over the life of the project. Analysis of cost results 
should address areas such as the amount and degree of deviation between 
estimated and actual costs, specific areas of cost deviation identified 
through the use of a detailed cost structure, and the validation of cost 
estimation techniques and models. The actual cost information recorded 
can provide a basis for evaluating the effectiveness of conversion tools 
and may be used to prepare recommendations for improved procedures 
that can increase the cost-effectiveness of software conversion. 
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POST CONVERSION MANAGEMENT CHECKLIST 

o Parallel testing terminated 

o Documentation completed 

o Conversion staff reverted to normal duties 

Informed of organization 
Informed of duties 
Trained as necessary £ 
o Contracts closed out 

t - SOW reviewed 
V •• Obligations met 

:}'■;■'■ V ■V^.',;Cdst issues (if any) resolved 

o Utineeded conversion facilities released 

o Nei^user Enhancements pending changes analyzed for 
redesign, V.-* 'jy.y' : v y' /■ 

o Ongoing costs being tracked 

o Post-conversion analysis completed 

Report complete 

Support planning and future conversion 
Coordinated with staff ** m 

Approved 

o Project manager released 

o Ongoing long-term planning base$ on full cost 
methodology; adequate to support 

A-76 Studies 
A-109 Studies 
A-ll Planning 
Budget 

Future conversion 

o Conversion technical planning ongoing 

o Conversion technical plans implemented to promote 
efficient, portable software 

Sof twara library maintenance and purging 
- File maintenance and purging 
Continuous user interface 



156 



Continuoixs top ^ecutiye interface and reporting 

Trdiniiig Supporting good software practices 

Security requirements reguljRr addressed 

Documentation procedures 

Standard language used 

Vendor unique utilities discouraged 

Software engineering practices 

fcileis designed for standard language access 

Test files and dftjta maintained and used 

Regular optimization of software 
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The following references should be part of any s6ftware 
conversion manager's library. 

FEDERAL DIRECTIVES: 

FPRl-4.lt Procurement and Contracting Government-Wide for 
Automatic Data Processing Equipment, Software, Maintenanc e Services 
and Supplies ] This regulation^ defines procurement and contracting 
policies relating to the acquisition of hardware, software, maintenance 
and supplies for ADP. " A " 

F P M R 101-35 A DP and Telecommunications Management Policy . This 
regulation establishes the general policies and procedures relative to the 
acquisition, management and utilization of ADP equipment, software, 
maintenance and supplies. 

FPMR 101-36 ADP Management . This regulation defines the 
requirements, policies and procedures governing the use, utilization and 
management of government ADP facilities. 

FPMR 101-37 Telecom munciations Management . This part prescribes 
policies and procedures governing the utilization of telecommunication 
services by Federal agencies. 

FPMR Temp. Keg. F-496 Federal Conversion Support Center . This 
temporary regulation advises agencies ot the reimbursable services 
provided by the Federal Conversion Suport Center (FCSC) for ADPE and 
teleprocessing services, software conversion support assistance, guidance, 
and support. This regulation replace FPMR Temporary Regulation F-492, 
Oetober 18, .1979, in that it removes the F-492 requirement for FCSC 
evaluation reports on conversion studies. 

Public Law 89-306 Federal Property and Administrative Servic es Act of 
I'M 9 (as amended by the Brooks Act, October 30, 1965y This Act 
establishes the authority to provide for improved afid efficient 
procurement, maintenance, operation and utilization of AjflP equipment. 
It «Iso establishes an ADP fund for use by Federal agencj- 

Public Law 96-511 Paperwork Reduction Act of 1980 . December 11, 
1980. The purpose of this Act is to reduce paperwork and enhance the 
efficiency of the (Jovernment. Specifically it calls for the improvement 
urn] increased efficiency in the use of ADP ;and telecommunication 
services. ; 

STANDARIJ6 AND (JUil)KUNKS: 

National liurcau of Standards. MI'S I'UH 31. Guidelines for Automatic 
l)»t_H P rocessing Physical Security hik! Risk Management . June 1974. A 
hiiridbook for stnjcluririg physical security and risk management programs 
* for ADP facilities. 
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Nation&l Bureau of Standards. FIPS PUB 38. Guidelines for 
Dbcumentation of Computer Programs and Automated Data Systems . 
February 15, 1976, This guidelines provides a basic reference and 
checklist for determining tfre content and extent of documentation of 
software programs. 

National Bureau of Standards.' FIPS' PUB 41. Computer Security 
Guidelines for Implementing the Privacy Act of 1974 . JMay>30, 1975. This 
publication provides guidelines for implementing computer safeguards 
(i.e., management of information, system/netyork controls, and physical 
security) as mandated by Public Law 93-579, th^rivacy Acjt of 1974. 

National* Bureau of Standards. FIPS PIJB 48. Evaluation of Techniques 
for Automated Personal Identification . Aprijpl977. Discusses techniques 
for identifying individuals seeking access to computer systems. 

National Bureau of Standards. FIPS PUB 64. . Guidelines for 
Documentation of Computer Programs and Automated* Data Systems for 
<the Initiation Phase . August 1, 1^79. This guideline provides a basic 
referertce and checklist for determining the content '-and scope of 
documentation for the initiation phas$ (feasibility, cost/benefit analysis) 
of a software life cycle. 

National Bureau of Standaipls. FIPS PUB 65. Guidelines T6r Automatic 
Data Processing Risk Analysis . ^August 1979, Presents a technique for 
conducting a risk analysis of an ADP facility and related assets. *• 

National Bureau of Standards. FIPS PUB 73, Guideline foi^Security- of 
Computer Applications . June 19&0. These guidejines describe methods 
and techniques that can reduce the hazards associated-: with Computer 
applications. # 

t Executive Office of the President, Office of Management and Budget, 
Circular No. A 76, Policies for Acquiring Commercial or Industrial 
Products and Services for Government Use . This policy document 
prescribes evaluation of government run operations, at time of major 
change (such as software conversion), to determine if operations can cost- 
effectively be transferred to contractor support. 

Executive Offiee of the President, Office of Managfement and Budget, 
Circular No. A 109, Major Systems Acquisition . This policy document 
requires studies to be performed in a prescribed method when acquiring 
major systems, including largS computer systems. 
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General ^counting Office, Millions in Savings Possible in Converting 
Programs from One Computer to Another ; FGMSD-77-34 (1977). This 
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aqd their problem areas. . ^ • 

General Services Administration. Conversion ProductS/Aids Survey .^ 

Federal Conversion Support Center. Report No. GSA/FCSC-80/01. 

August 1980. This report describes in detail many of the conjTneroially j 

available automated conversion packages and aids currently available to 

the Government. ' * 

§ 

General Services Administration. Conversion Study Outline . Federal 
Cdhversion Support Center; August 1980. This 'document , provides a 

• checklist for identifying and cataloging source programs and data files 
subject^ conversion. m 1 

GeneVal Services Administration. Review and Apalysis of Conversion 
Cost-Estimating Techniques . Federal Conversion Support Center. Report 
No. GSA/FCSQ-81/001. A*pril 1981. This document identifies and 
evaluates seven • conversion cost estimating techniques available to 
agencies. 'Each technique is briefly examined in terms' of ijft advantages 
and disadvantages. 

* National Bureau of Standard^ Conversion of Federal ADP Systems: A 
Tutorial Specie^ Publication 500-62. August 19|fl. This' document <' 
presents irv tutorial fashion an analysis of severs* recent conversion 
projects wifh observations atid salient problem areas identified. Several 
case studies are included. - 

U.S. Army.* v Army Automation Planning Guide for Software Conversion . 
Technical Bulletin 18-122. October 1977^. This report presents a detailed 
outline of th% oOhversion preparation process* including bptn pre-award 
and post-award actitfcaes. " * ■ * 
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APPENDIX C 
SOFTWARE CONVERSION COSTING 



The information contained in this appendix has been developed 
to provide guidance for the practical application of the concept of full 
costing to the management of software conversion projects The purpose 
of this appendix i& to define the approach, or methodology, that should be 
followed in developing software conversion costs. The approach presented 
is intended to be a generalized methodology and attempts to discuss cost 
considerations intt enar al terms This total system approach can then be 
modified, as appflPlate, to fulfill the specific costing requirements of 
each software conversion project 

It is important to understand the steps for developing a total 
conversion costing methodology. The methodology consists of two parts. 
The first is the definition of full conversion costs which requires: 

o Identification of project characteristics, 

o Development of the full cost structure, 

o Estimation of the cost data, 

o Analysis of the cost data. 

The second part is the application of the cost data to support 
management decisions. The remainder of this appendix describes these 
steps in more detaiL It is important, however, to continue to view costing 
in terms of a total methodology, to assure that the maximum return is 
obtained from the costing development effort. . 

C.l INTRODUCTION 

a Software conversion project managers are required to prepare 
budge^, monitor the progress of programs and projects, estimate the cost 
of new capabilities, and make a variety of other system-related decisions 
on a frequent basis It is the objective of this appendix to provide a 
consistent cost methodology tjiat can assist the project manager by 
ensuring that the required conversion cost data is &ot|& available and 
reliable. Also, by providing a consistent costing methpdolbgy, historical 
costs can be uniformly accumulated and updated to^inc|ea^e the'acfcuracy 
of future estimates. ^ | 5 

C.l.l SCOPE OF THIS METHOlSloGY 

The identification of software conversion cc^sts addressed in 
this appendix includes all major cosfcifactors directly attributable to a 
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software conversion effort. The software conversion project may be 
conducted as part of a total hardware installation effort, with planning, 
analysis and implementation tasks being Conducted concurrently. The 
scope of this appendix, however, will be limited to the software 
conversion effort which is just one major factor in that hardware 
transition effort Other hkrdware-related costs such as site preparation, 
installation, and ongoing operations will not be included. Identification of 
software conversion costs will include both direct and indirect costs that 
can be identified with the conversion effort, and may span organizational 
boundaries and include the user community costs. 

If the software conversion is accompanying hardware replace- 
ment, the costing of the software* conversion effort should form an 
important input into the life cycle cost (LCC) of the total acquisition 
effort. The total LCC should include the total cost of acquiring, 
installing and operating the ADP system from the inception of the 
acquisition process until the system becomes obsolete. The development 
of accurate and detailed software conversion oost estimates will not only 
aid the conversion project decisions but will also aid in the selection of 
the total system acquisition, alternatives. „ The software conversion 
project manager should assure that a single cost estimation effort is * 
? conducted where software conversion cost estimates are supplied to the 
total acquisition LCC, and where acquisition decisions are communicated 
to the conversion project to be reflected in the software conversion cost 
estimates. This sharing of cost information can prevent situations where 
ambiguous and conflicting costs are reported to upper management 

C.1.2 CONVERSION COST DEFINITION 

* The first step in the understanding of the conversion costing 
methodoldgy is the definition of conversion costs. This can be 
accomplished by identifying the full cost structure that represents the 
software conversion effort, and by defining the length of the software 
conversion cycle. % m 

C.l.2.1 Full Costing 

ri 1 

Full costs of a , software conversion include the obvious direct 
costs of ADP employees and software conversion tools Indirect overhead 
costs such as space rental, ADP management and support costs can also 
be identified or reasonably allocated to a particular conversion effort, 
especially if the costs are incurred within a particular agency. The 
biggest problem of defining the^full costs of a system occurs in the user 
community, or in organizations beyond the control of the ADP facility 
management or evei\ the agency management. . * 

C.1.2 .2 Conversion Cycle Length 

The length #f the software conversion cycle depends upon the 
beginning point, when costs begin to accumulate, until the project has 
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been completed. The following factors should be considered ia 
determining the project cycle length: ... 

i." o Beginning Point - For the purpose of this appendix, the 
; : > beginning event for the estimatiojvof costs is assumed to 
occur with the appointment x>f a conversion project 
1 manager. This point does not hecessarily coincide with 
■ •;.."* the beginning of the - software conversion # ef%t since 
software conversion has 9 continuous ^ife c^cle. Each 
life 'cycle has a distinct project, febwgveif • kid' 
develppment of project costs is the important .iss^e. 
With the appointment of a project manager: ^< 

Costs can be clearly identified wi.th a particular 

v project, and, V 

; ; . . . . • : . •• -V." ; . • 1 ■ • 

Accountability for costs has been clearly 
established. ' /* 

If, f^£ some reason, significant project-delated costs, 
have been incurred piior to the appointment r of a project 
manager, these costs\should be retained in tH^ historical 
cost records. ~ \ , ' ^ 

o Ending Point - For cost estim^ton purposes, the 
software conversion project e ^ < MS^^|^ vers ^ haS 
been completed, conversion ^^p^p^^wave^bcen 
reassigned, and the post-cbnversi^^t^^ and analysis 
have Jieen ^ompleted 

The subject 6f costing — its definiti 
project management has ,no single, cookbpj 
applied for all projects. Instead, what is nee 
addresses the costing requirements of manage 
guidance that can, mold the <methodojogy to th 
project. This is the- approach taken by this appe 

G.2 G0NVEBSION COSTING M|TOOIX)LOG||vt 

W process. 'tQ^i&fcsYed jn identifying the full $*st of the conversion 
effort/ is ill^^il^d in Figure C-l. The* major steps in this,, process* 
include: ^ * ■ < " 

' ' ■ / ' • ^ Q 

\</V Characterization of the Conversion Effort 
' , ? ' ( inclHdes^ A gene^Ll understanding of the project goals _ 6 

" " >i> : bbjea|tives,^ource environment, potential target envirorv# 
m ' rnenfs, current software inventory dnd inventory status. * 

• 
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-o -Definition-of-a-Gost-Structure - The cost structure 

should reflect the requirement for more detailed cost 
information as the project progresses and should include 
major categories of cost 

o Estimation of Costs - Defined by the cost structure using 
resource and price estimates developed from historical 
data, models, price lists, industry sources, etc. 

o Analysis of the Cost Data - Specific analysis objectives 
are based on the requirements for the use ol cost data by 
project management 

o Application of the Cost Data - To provide specific cost 
input for costing decisions and activities. 

Each of these steps is described in more detail in the sections that follow. 

C.3 CONVERSION PROJECT CHARACTERIZATION 

The characterization of the conversion effort is an important 
preliminary step in the execution of the conversion costing methodology. 
Through a thorough evaluation of the major characteristics of the 
conversion project, a cost structure can be developed that reflects the 
material costs expected to be incurred and allows for the> application of 
costs, with sufficient detail, to fulfill expected management 
requirements. & 



A conversion project may be characterized using several 
factors including: 

o Software environment eg., current languages used, 
whether they are in standard ANSI language, degree of . 
documentation, 

o Multiplicity, e.g., whether the conversion involves 
multiple sites, systems/ or user organizations, 

o Financial impact e.g., whether the expected dollar size 
of project will require increased reporting efforts, 

o Mission supported, e.g., whether workload cycles will 
restrict the project schedule. 

This characterization step should result in an informal, written 
understanding of the relevant project characteristics stated in' terms of 
the project's goals and objectives. This understanding should be approved 
by the project manager during project initiation in the development of a 
conversion cost structure. This understanding should also be reviewed 
periodically throughout the project and revised as needed. 

: ■{ < - 
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C.4 COST STRUCTURE DEFINITION 

The primary, component of the methodology is thef design of a 
comprehensive cost structure that ^addresses the full cost of the 
conversion, aids in the estimation of conversion resource requirements 
and price factors, and allows the application of a single cost information 
t>ase to several project costing needs. The cost structure defined in this 
appendix meets these requirements through the use of cost dimensions. * 

A cost dimension is a classification scheme that identifies a 
particular characteristic of an entire project. For example, project costs 
may be recorded as> follows: personnel. $75,000, equipment $10,000, 
facilities $10,000, miscellaneous $5,000 The cost of the project may also 
be defined along functional terms, such as, conversion $80,000, training 
$12,000 and administration $8,000 In a similar fashion the total project 
cost could be divided into cost per phase, cost per year and so forth. In 
each case, a summation of jcogts along any dimension would yield the same 
result, or in this example, $luu,000. 

The purpose of the dimensional cost structure is to minimize 
cost ambiguities in addition to providing the following: 

\ o Assistance in defining the full cost of a project, 
o A work breakdown for ease of cost estimation, and 
o Detailed cost information for use by project 
management 

The full cost of a project can be defined - using single 
dimensions and* similarly, a summation of costs along each dimension 
would yield the same full cost figure. / The benefit of a dimensional 
approach is the ability to identify categories of cost (such as software 
conversion personnel costs) that span several dimensions. The following 
dimensions should be included in the software conversion cost structure: 

C.4.1 COST ELEMENT DIMENSION 

Cost elements correspond to the basic accounting units that 
represent personnel, material and facilities The cost element dimension 
has been developed for this cost structure using ADP terminology and 
providing a level of detail that is consistent with the amount of funds 
normally expended for each category. It is the responsibility of each 
project manager, working with the cost analyst, to identify the cost 
element level of detail that reflects the characteristics of the project and 
supports the application of the conversion costing methodology to the 
projects needs. 

The cost element detail that follows is illustrated in Figure i> n , 
and should be viewed as general guidance. Important cost areas may be 
expanded if they are material to the decisions supported by the costing 
methodology. Elimination or consolidation of the cost element 
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PERSONNEL 



OCCUPANCY 



• COMPENSATION 

• GENERAL BENEFITS 
•,. TRAINING EXPENSES 

• TRAVEL AND TRANSPORTATION 
EXPENSES 

• HIRING/SEPARATION EXPENSES 

• MOVING EXPENSES 



i 



facilities ■ 
utility service 
office equipment 
Housekeeping expenses 

security expenses 
environmental controls 
other occupancy . 



ADP HARDWARE' 



ADPE SUPPLIES 



OPERATING UNIT 
DATA ENTRY DEVICES 
PRINTERS 

TIMESHARING SERVICE 
EQUIPMENT MAINTENANCE 

OTHER ADPE 



ADP SOFTWARE 



MISCELLANEOUS EXPENSES 



OFFICE SUPPLIES 

TELEPHONE SERVICE 

PRINTING/DUPLICATING 
EXPENSES 

SMALL CONTRACT SERVICES 
OVERHEAD 

GENERAL AND ADMINISTRATIVE 



OPERATING SYSTEMS 
CONVERSION SUPPORT SOFTWARE 
GENERAL PURPOSE SOFTWARE 
SOFTWARE DOCUMENTATION 
SOFTWARE MAINTENANCE 
OTHER SOFTWARE 



TELECOM MUNICATIO NS 

/ . . ■ r 

• LINE CHARGES 

• TERMINAL EQUIPMENT 

SOFTWARE CONVERSION COST ELEMENT DETAIL 
Figure C-2 
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dimensional detail should be done only with careful consideration as to the 
impact on the cost estimation techniques and the ultimate application 
potential of the resulting structure. . 



The following is a definition of each significant cost element: 

o Personnel - The per5onnel cost element will normally be 
common to each software "conversion project and 
account for a significant portion of the costs. Personnel 

/ costs are also the m<*st likely to be underestimated 
either through an incomplete definition of the work to be 
performed, quantity of personnel required, level and post 
of skills required, or amount of ancillary personnel costs. 
The personnel cost element consists of the following stfcr 

, elements: 

Compensation - includes base wages, cash awards, 
r> ^overtime pay and premium pay in the form of shift 
differentials, incentive pay, merit pay, and. other 
allowances for all regular, part-time, permanent 
and temporary employees^ ; 

General Benefits - includes eriiployer-paid thedical, 
dental, life- and disability insurance, and. 
contribution to non-social security retirement 
plans, federal and locally-imposed payroll taxes 
such as FICA (social security), FUTA 
, (unemployment), and workman's ^compensation 
r tax6s; and other benefits such as professional dues 
and memberships, subscriptions, awards, uniform 
cost and . cleaning, and any other personnel 
expenses that are not otherwise described. H 
. ' ' " . '. p- ■ 

- Training Expenses - includes expenc^taces fpr 
tuition, fees, educational books, materials / arid* 
training aids. ; ' " 

Travel and Transportation Expenses - includes the 
transportation of employees for business, training 
or relocation purposes. It includes actual' 
transportation expenses for auto, airlines, bus, and 
train travel, as well as meals, lodging, tolls, tips 
and other travel expenses. 




iring/Separation Expenses - includes advertising 
osts, credit/background investigations ' «£ees, 
" ploy ment. agency fees, testing service f$es 9 and 
'^placement fees. 
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Moving Expenses - includes the cost of transporting 
. personal prbperty^siich as the shipment of 

* 1 household goods, j|^£rty storage, closing costs, 

and mortgage in ter^ adjustments. 

• • r 

In addition to the personnel cost categories listed above, it 
may be beneficial to be. able to identify personnel salaries bas^d upon 
individual skill categories. This process will assist in thp estimation of 
salary expense by providing common job titles, and will aid in the. 
application of the costing methodology for ; alternative evaluation 
purposes.\A personnel skills category definition would be applied to the 
salary cost element and, in the federal government, would contain , costs 
by job title, GS level and GS step. 

o • ADP Hardware * ADP hardware' expenses may, be 
incurred during the software conversion effort in terms 
of CPU hours purchased from a service bureau or 
. . provided by the equipment vendor,- or target equipment 

' obtained on a short-term basis to provide the test 

. environment and on-line conversibn capabilities required 
* during the project . Subelements of this category 
include: 

Operating Unit - includes the mainframe, operator 
: consoles, storage and memory devices, acquired for 

v. trie project, ; !*'"■''< 

" ' ' ' \ • ■ . • i « ■ • ; ... \ 

- Data Entry Devices - includes.. the terminals and 
j other input equipment, : v . , • / . 

■ * •• *• ,f •* 

, - , Timesharing Service - includes the cost of 
timesharing services used durjng thet, project, 4 f 

- Equipment Maintertence - includes the cost Qf 

t normal hardware maintenance ser^ic^ cQntrflcts," 
•'• Other ADPE - includes ' ADP equ^m^Qt not 
included above, such as tape cleaners, nardwar^. 
'monitqrs, test equipment, and spare parts. V 

" • < * 

o ADP Software - ADP software includes art ever- 
increasing proportion of ADP costs as datS* processing 
installations use more canned programs, and less in- 
house software is developed This cost element includes 
only purchased * or leased software. ADP spftware« 
v includes the subelements of: • * 

Operating Systems - includes the mainframe 
operating software including spooling software, 



Conversion Support Software - includes the system 
support Software such <;as compilers, utilities, 
translators, and tools; 

General Purpose Software - includes multi-use 
software such as SAS, SPSS, RPG, etc., 

- 6 Software Documentation - includes the manuals, 

guides, and software handbooks obtained for iise 
with the ADP software, 

Software Maintenance Service - includes the cost' 
. of normal software maintenance servicercon tracts, ., 

Other software - includes other software-relatecj 
r costs. 'V - 

Telecommunications - The ^lecpmmunication^ cost 
element includes- the hardware and service required to 
provide date -communications between ADPE components 
to support, software conversion This element includes 
the following subelements: 

5 , 

Line Charges - include • the cost of leased lines, 
trunks or network service, . . * 

Equipment - includes* the cost of modems, 
* ^concentrators, front-end processors, terminals 
equipmenfciTjainten^nce service. < > 

z.^fi^^M ■. • ■ . . , . 

' Qccupaft^ ili^p^f occupancy, or space cost element is 
used to|fi^|i^ilhe costs required to house the project 
tetfm. ti^Jaf cost element that has been occasionally 
overlooked, sirice occupancy costs are frequently borne 
by a service agency (e.g. GSA^, The occupancy cost 
element consists of the foUowmg^subQlemente:/ 

Facilities - include the building, land, common 
areas, leasehold improvements, and other pi hys teal 
structures, ' r ^ 

Utility Services .- include electric 'power, gas, oil, 
coal, water, sewage and garbage service, * 

- ^ Office Equipment - includes; the general office 

furniture and fixtures, typewriters, copters, plants, 
pictures, decorating fete^etc., * 

> Housekeeping Expenses - include janitorial supplies 
and equipment, 
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S ecurit \Hlxpenses - include the access cards, 
i'miihtms, locks, monitors and alarms required to 
* control access to thf building or t ho computer 
installation, 

Enviro nmental Control s - include the normal 
heating and air conditioning equipment expenses as 
well as an uninterrupted power source, humidifiers, 
dehumidifiers, water chillers, 

Other Occ upancy Kxpensos - i no lu de all o th er 
occupancy -re la ted costs not included above. 

A DP Sup plies - In a typical API 1 operation, \\)V supplies 
ran account for a small, but significant percentage of 
costs. For this, reason, a separate cost element is 
assigned, to distinguish the ADP-rolatod^supplics from all 
other supplies. *• : ^So 

* . . ■ - { \ ■ : 

Miscellane ous lixpenses - Miscellaneous expense is a cost 
rleTvTent that i incorporates costs not *spoei|jcally detailed 
by the prior cost elements. It should 'Include general 
categories of expenses that arc not A I ) ^ related. The 
characteristics of each project will determine the 
materiality"' of the subolemonts defined for this cost 
element. The list of subeleinents that follows should be 
used as a guide that can be expanded as needed to 
provide a consistent level of cost detail 

Offi ce Supplies - include general administrative 
office supply that are not directly API'-related. 
Lhese would include pens, pencils, copier paper, 
pads, folders and the like. 

I'elephone Services - include the charges for local 
service, long-distance and special voice 
communication lines. 

Printing Duplicating Kxpenses - include the, cost of 
usir^j off-site printing and duplicating services. 

Small ("on tract Services - include the rotative ly 
small contract services that cannot.be defined in 
terms of olher cost elements, or are too small to 
►>e of nwterwl sigruf icanee- Major software, 
conversion contracts should be identified by the 
specif ic .resources (amount and price)' being 
provided to allow a detailed identification of ccVsts, 
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- ' Overhead - includes indirect costs associate with 
the performance of a project that cannot be 
. defined in terips of otheffcost elements, or are too 
small to.be of material significance. The use of 
this overhead category should be &ept to a 
minimum since the objective of th&co'st structure 
is the identification'of the full cost detail 

"ft' <<V, 

General and Administrative (G&A) - similar to the 
overhead category, G&A is, common in the federal 
government as a means of allocating indirect costs 
to an operating unit. As with overhead, the use of 
the G&A element should be summarized and 
applied only when a cost detail is not ^ available or 
the amount of the cost is relatively insignificant 

The cost element dimension detail provided in this section 
should be used as a foundation for the construction of a conversion cast 
structure that is representative of ttfe software conversion effort and 
reflects the full cost of the project. The furfction dimension discussed in 
the following section serves as an additional means of 'assuring that the 
full costs of the software conversion are addressed, 
t 

C.4.2 FUNCTION DIMENSION 

Functions are general categories that may include one or ,more 
activities that are performed during the software conversion project. It is w 
important to distinguish between functions and activities. From a project 
management standpoint, activities are important for establishing -project 
controL Conversion activities may not require a substantial amount of 
resources, for example, the appointment of a project manager. From a 
cost estimation standpoint, however, conversion .functions better 
represent the conversion effort. The function dimension-Is included in the 
cost structure since it aids in the identification of the full cost of a 
software conversion project by identifying all significant Junctions. Also, 
the function dimension helps in the cost estimation process by providing 
cost categories that corresp6nd to existing software conversion cost 
estimation models, and ate sufficiently derailed to provide a work 
breakdown structure with which to develop costs. A consistent* set of 
software conversion functions caln also aid in the use of historical costs to 
estimate future software conversion costs. The following functions' 
illustrated in Figure C-3, corresfoorjd to the conversion tasks identified by 
the Federal Conversion Support Renter and include: v ^ 

* o Conversion JVranagement and Administration - includes 
the resources involved in managing arv% administering the 
conversion eir?tfi*S w $uch as user and ufcper management 
liaison, contract administration, and personnel activities* 
involving the project team. 
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CONVERSION MANAGEMENT AND 



ADMINISTRATION 



SYSTEM AND PARALLEL TESTING 



CONVERSION PLANNING ANALYSIS 
AND PREPARATION 

• PROJECT PLANNING 

• STUDY PREPARATION AND . 
SOFTWARE INVENTORY 

. IDENTIFICATION 

• POLICY REVIEW 

• SOFTWARE WORK PACKAGE 
PREPARATION 

• TEST DATA GENERATION 



APPLICATION PROGRAM AND SYSTEM 
SOFTWARE CONVERSION 



TRAINING 




CONVERSION TOOLS 

• TARGET SYSTEM AND TARGET 
SOFTWARE 



SOFTWARE UPGRADE 

• CONFORMITY TO ANSI STANDARDS 

• COMPLETE CURRENT SYSTEM 
DOCUMENTATION 
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• FUNCTIONAL SOFTWARE REDESIGN 
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TRANSFERS ONLY 
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Conversion Planning, Analysis, and Preparation -includes 
the preliminary conversion activities suCh as: 

Project planning and analysis at the project, 
system and task levels, and identification of the 
conversion work package, 

Study preparation and software inventory 
identification including quantity, language, age, 
documentation, etc., " t 

Review and implementation of conversion policy, 
procedures and documentation standards, 

Preparation of the software work package, 

Test data generation and validation. 

Application Program and System Software Conversion - 
includes the resources required for reprogramming, 
program logic modification, simple translation or other 
methods of software conversion, including the use of 
conversion translators and aids. 1 ■> ■ 

Data File Conversion - includes the following types of 
conversions: 

Transfer only - where the source and target 
systems and environments are fully compatible, 

Simple translation - where the conversion is 
basically character-to-character, from source to 
target character set, on a one-to-one basis, 

Average complexity translation - which involves 
cha r ac te r- to-c ha rac te r, c ha rac te r- to- w o rd, or 
word-to-word conversions with the conversion 
parameters embedded in the files, 

Complex translation - where the conversion para- 
meters are external to the files These conversions 
usually require development or modification of 
several pieces of conversion software and generally 
call for multiple steps, 

Very complex translation - usually includes DBMS 
files and may require major development of special 
software, 
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Operation Control Language Operating Procedure 
Conversion - includes the resources Quired to convert 
the operating procedures ^from' »ne environment to 
another, including rewriting, repro^niming, and the use 
of operation control language trans^tQij^ and generators, 



Redocumentation - includes the resources used in 
reviewing and analyzing existing*" documentation 
rewriting, and clerical editing, proofing, and typing of 
the new software documentation, , « 

System and Parallel Testing includes the resources used 
in the system^ test and parallel test .of the ^ystem. to 
demonstrate interoperability betwegri^System compoft- 
ents (programs, files, and j#> streams) and overall 
correct execution. When the system functions as 
expected, software acceptance testing* would commence 
to achieve acceptable comparisoh of outputs against th<T 
purrent or source system resfllts/ • ^ 

Training - includes the resources used in training course 
preparation, delivery tnd pfcirticipatiol^for the following 
/ activities: • / * 

* J • 

Traiifing which trains the project team in new 
conversion ^techniques or the use of software 
^ conversion {pols,* ^ 

^Training* wtrich trains functional users, DP staff, 
proje%t teay and other personnel in the target 
% system environment, and target system software. 

> Software Upgracfe - used to iden tify sof twa re cost s 
incurred during a conversion not directly associated with 
ntew hardware. These costs must be budgeted and 
tracked, but may or may not be included for hardware 
evaluation purposes, depending upon the regulations 
currently in force Software upgrade^ccurs whenever 
* current applications are changed to conform with 
government ANSI standard language, documentation is 
developed to provide a complete description of the 
current systems, obsolete programs are purged, or a 
functional redesign of a program' is performed, 

General - if designed as a default category witH whiqh to 
identify functions not specifically addressed above. 
Examples of functions that could be included in "this 
category include v facilities maintenance, production 
control, and security functions. 
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PHASE DIMENSION 



The phase dimension corresponds Ao the softwa 
phases described in the body <k these guides, ^hase dimensi 
in large projects in providing a logical and somewhat sequent 
of conversion activities that provides be.tter upper manage"" 
through the use of milestone approval points. Through 
assignment of software conversion activities to phases, historic 
from many projects may be recorded in a consistent manner and 
future cost estimates, and to develop and validate cost estimation mc 
It is important to note that the definition ^ " * 
overlap That is, .as one phase is being co- 
phase are already being performed. T" 
identified in the dost structur#include: 



phases will result in 
activities in the a 
conversion ph 





"the detailed *% 
%$kjl& pe r f o r m ed 



6r 



Project; Initiation Phase - wher&J 
undertake' a conversion effort, 

Conversion Requirements Phase 
j/estigation and identification fitct^^ ^ . 

> Conversion Planning P hase Vwhere:M Conversion plans , 
\and schedules are developed in^eta^' fee^M -upon require- 
ments defined in the previous phase,' .' ^ r j .' ' ° 

Conversion Preparation Phase - wherethe activities.that 
are require^ to , fcegin the conversion process are 
completed, ;•£'*' > . " . ••>/'* -.A 

Conversion Phase -$w\ere the' activities; identified "to 
perform the trans%%&f software"- |rom the source 
environment to the^r^I^^ironmejfiiis: accomplished; 

i ■ ^ ,; . , , 
Post CetflB fcion PfiSsft, -vr-wner^ r tbi' conversion t 

arra then post 





iam is 
irsion 



n^rial" duties 
/sis, is conducted. ' - \. . 

While costs may be MflKirred pri'or' to the appointment, of a project 
manager, in the project initiation phase, <$$#*er a ^post-emersion 
analysis, they are not included as estimates .fi«phe*Software conv.er^n 
project cost. Activities in these areas fair outside ..th» perspective^! 
viewing conversion as a "project" The conversion project costsfc ue. 
those that are .incurred from the time a project is started through- , ^ 
completion are the most important. More detail concerning the s^ific^yf; • 
activities included in each software conversion phase can be foundgn the 
body of these guides. The relationship between the cost. elemtftt, |jj|jction 



and phase, dimensions is depicted in Figure C-4. 
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Cj4.4 TIME DIMENSION 

) ' ^ 

The time dimension identifies the calendar period in which 
T costs are expected to be incurred. The time dimension is included in the 
cost structure for budgetary purposes to assist in project planning and 
^ control, and to aid in present value cost analysis for relatively long 
? software conversion efforts. The detail incorporated in the time 
dimension should reflect the use of the cost information by project 
./management and the ability to accurately estimate costs. Thus, during 
v ' project initiation, software conversion costs used for a cost-effectiveness 
• analysis may be estimated for the next four quarters, and annually 
thereafter Prior to the commencement of the conversion phase, 
however, costs may be required to be estimated for each month for 
project control purposes In general, software conversion costs should be 
estimated at least by fiscal year and for periods not shorter than a 
month. 

# 

C.4.5 i LOCATION DIMENSION 

3 The location dimension identifies the geographical site where 
a function of the software conversion is being performed. It addresses 
personnel, equipment and occupancy resources, the price of which may 
vary by location Thus, the use of a location dimension aids the 
conversion costing methodology by allowing the estimation and analysis of 
geographic cost differences relative to the total conversion cost figure. 
The location dimension should be included with software conversions that 
involve multiple sites. 

e.4.6 PRODUCT/SERVICE DIMENSION 

The product/service dimension is used to allocate the cost o£ 
the conversion to specific operational objectives performed by the 
facility These objectives could be stated as ADP services (e.g. 
timesharing, batch processing), programs supported *(e.g. anti-aircraft 
missile, solar energy) or applications processed (e.g. general ledger, 
payroll, disbursements, personnel). Where more than one product 
classification is appropriate different product dimensions may be 
.material. This dimension will allow the project manager to estimate the 
cost to convert each individual system or conversion unit. 

- C.4.7 ORGANIZATION DIMENSION 

The jorganization ^dimension identifies the component, agency, 
department or division that' performs functions of the project. In this 
respect it assists in the identification of the full cost of a project by 
^ providing a structure definition that extends beyond the budget concerns 
• of the primary* organization. The organization dimension also aids in the 
identification of inter-and in tra-govem mental support in performing 
conversion functions. . * 
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The identification of* the conversion cost structure jif^he first step in the 



development of the cost of a software conversion flcoject. Through the 
project, the estimation of the individual cost detail, and tfl^analysis and 



use of cost structure dimensions, the identification m the fujUftsost of the 

tfSFai 

application of the estimated costs can be assisted. 

C.5 ESTIMATION OF COSTS j 

Once the cost structure has been identified fay the specific 
conversion project, estimates of cost must be developed for the structure 
detail. This section presents^ this cost estimation process in both a 
general and specific format 

It is difficult to ideatify a single, universally acceptable 
approach to estimate conversion costs The estimation technique used 
will vary with the degree of accuracy required, characteristics of the 
software conversion project, and the use of the cost data during the 
conversion phases. The basic steps*required to estimate costs include the 
following: n 

o Idehtify the Conversion Cost Structure Detail 
Appropriate for the Project - This is accomplished by 
using the multidimensional cost structure described in 
the previous section. The cost structure can aisist in the 
cost estimation process by dividing the conversion cost 
into manageable pieces. J* » 

%r o Estimate Resources - The next step in the cost 

L estimation process is to identify the quantity of 
resources required to perform a given conversion 
function. The cost element dimension provides the list 
, of resources, while/the function dimdhsiofi identifies the 
- workload requirements. Since' resources will rarely be 
100% utilized, an adjustment shoul^jlfe intruded in the 
resource estimate to provide excess capacit^ftvhether in 
•f terms of man-hours, processing time,^p ; spite require- 

ments. , . Wf : 
# ■ i < : 1Wr 

o Estimate Unit Price - The price of p: given resourc^ (or 
cost element) unit must be estimated The price may be 
dependent upon the conversion function performed (e.g 
skill level required), location and time period. Price can 
be affected by inflation factors, government discounts, 
or quantity discounts. Multiplying quantity tiAies price 
will give the cost gf a single aost structural unit* 

The estimation process is not static throughout the conversion 
project. The use of cost estimation models and techniques at the 
\ beginning of the conversion prcjpct may be sufficient to provide the 
accuracy for a limited cost-effe#nveness analysis. Later in the project, a 
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given cost estimation model may not provide the accuracy necessary to 
estimate 4 the structural cost urjits. The degree of estimation will also 
change during the conversion project phases. • For a large conversion 
project, costs may be adequately expressed to the nearest^^OOO during 
the project initiation phase. Later, costs may be required to" the nearest 
hundred dollars The dimensional levels of detail that are material can. 
also change during the project. When dealing with broad cohversipn 
strategies it may be possible to estimate at a gross level ^ detail* Later, 
increasingly finer levek of detail will be defined. • Tfcost estimation 
techniques th^t address a gross detail level jmay not£e Appropriate to use 
in estimating the lower detail levels of the conversion cost structure. The 
estimation process described in this section must be used with comtabp 
sense and adjusted to fit the characteristics of the individual project and 
its changing requirements for cost information during the project phases. 

v» 

As a~ basis for the specific cost estimation process, the 
following section presents a general discussion of J$ost estimation 
techniques that may be applied. " 

C.5.1 ESTIMATION TECHNIQUES (GENERAL) I 

The cost estimation techniques can be used to supply the cost 
figures for the cost*data defined by the conversion cost structure. Cost 
estimation techniques may be simple, such as using a previous conversion 
project's supplies cost and adjusting for inflation; or complex, as in the 
case of a parametric software conversion 6ost modeL The following 
general techniques may be used to estimate costs: 

o Standards - The use of standards relies on estimates for 
resource quantities and price that have been systemati- 
cally developed in the past. These standards then 
become stable reference points from which new. tasks - 
can be calibrated. Due to ragidiy changing ADP 
technology, > past ^performance si^ffWards, such as a 
standard for fronversion productivity (eg., number of 
line^onverted pet workday), should be examined before 
they are applied to ffstimate resource requirements for 
current systems. / v *. 

o Modeling - Modeling techniques attempt to predict cost 
or resource requirements for the proposed system* 
without the use of a full-scale development and trial 
period* Modeling techniques, such as the Federal 
Conversion Support Center cost estimation mochgl, are 
useful during the eajly phases of the conversion project 
planning process to provide an estimation of cost. As 
such, they can be useful during preliminary cost- 
effectiveness analyses to determine the cost impact of 
>osed alternatives. 
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o .Historical Cost Application - The use of historical costs* 
is generally limited to the refinement of future 
conversion p^iase cost estimates base^ on cost data 
collected for recently-completed conyersior) phas^ If 
historical cost records have been maintained, for 
example, the cost- of regularly scheduled management 
review meetings, these costs could provide the basis for 
developing accurate cost estimates for use throughout 
the project. v ' 

C.5.2 SOFTWARE CONVERSION COST ESTIMATION MODELS 

The difficulty in accurately estimating the cost of software 
conversion has led to the developmfnt of cost estimation models to 
provide a simple solution to the estimation problem. While a complete 
description of the use of models is beyond the scope fcLthis^appendiXj^Jie 
models summarized below serve as an overview to provide guidance as to 
the models currently available at the time of the publication of this 
guides that have significant application to federal .conversion and the 
strength and applicability of each. The use of software conversion 
.estimation models should prove beneficial in the iearly phases of the 
conversion where only gross detail is fequired and accuracy is not critical. 
These models should be used only with a thorough understanding of the 
basis upon which the model'was developed, the cost elements, functions or 
phases covered by the model, and^the projects in which the model output 
has been validated. # 

o Federal Conversion Support Center Model - The Federal 
Conversion Support Center 'FCSC) model was developed 
in 1980. The FCSC mod^l is primarily a parametric 
software conversion cost estimation model The model 
features an excellent breakdown by functions which 
facilitates cost estimation. The\nodel includes most 
cost elements, and it explicitly states those elements it 
does not ^include. The model is sufficiently flexible to 
handle most 6'omplex conversions, and covers essentially 
all phases of a conversion effort While the FCSC model 
has not been extensively validated at the time this guide 
was prepared, it' appears to be the best software cost ^ 
estimation modeVavailable from public sources. 

- - /Tire "FCSC Model fias "several distinct- advantages. 
Although incomplete, this model does have a 
comprehensive treatment o*f costs. The FCSC 
model was designed to ^ applicable to a. wide 
* range of conversions and there are plans for future 
enhancements. On- the other hand, the coefficients 
and values assigned for DBMS and other complex 
conversions are untested. Subjective assessments 



V 188 , 



\ 



166 



are required in* certain cost areias and it does not 
/ recognize effects on conversion costs of over- 
assignment or under-assignment of personnel. The 
applicability of the model appears to be universal* 

o Project Management Control System II - Project 
* Management Control System II (PMCS), which is also 

known as the Navy Model, was developed byH^aval Data 
..Automation Command (NAVDAC). It is a parafltetric 
software conversion cost estimation model which is 
based on batch-ta-batch. COBOL conversions similar to 
those performed in the 1970 ? s t at NAVDACs (then Data 
Processing Service Centers); PMCS is based on four 
similar conversions encompassing over 100 man-years of 
work. These conversions were primarily business 
oriented, batch, COBOL systems. PMCS is primarily 
oriented towards professional staff^days, hot towards 
dollars. It excludes discussion of costs such as admini- 
] stration, data entry, computer operators, and supervisory 

time which can be significant, in government ADP oper- 
ations, but not the associated costs. PMCS includes a 
management reporting system and automated manpower 
estimating aids. Reports ' produced are, however, 
> prim^ily a recompilation of data provided by the user. 

PMCS is relatively easy to use, validate, and refine, and 
is apparently not limited by hardware (assumption of the 
model's developers). It contains excellent coverage of- 
the phases of a conversiorr ef fort. ^PMCS is- based on 
data of questionable statistical value, 'bpcause some of 
the original data was discarded. Furthermore, the model 
— i« based on major conversion efforts and thus' may not be 
clearly applicable to small and medium-sized conversion 
efforts. PMCS can be used for batch^to-batch, business- 
oriented, COBOL to COBOL, flat-file to flat-file 
conversions.^ 

. It is not always possible to draw a distinction among the cost 
estimation techniques described above. They do have one common factor 
i^ their use of historical information to predict future events'; It should 
be evident that\if softwar^conversion cost information can be recorded in 
a detailed and consistent manner, for historical purposes, the accuracy of 
the cost estimation process, in general, can improve. 

C.6 ANALYSIS OF THE COST ,DATA 

Just as estimation techniques vary according to the require- 
ments of the project for Which costs are estimated, the analysis 
techniques that are appropriate for each situation depend upon the 
characteristics of the project and of the decision being qcfdressed. This 
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section describes several analysis techniques th'at;iare applicable to a wide 
range of situations. The applicability. of each technique is dependent upon v ^ 
factors such as the phase, function and alternatives analyzed for a 
particular project. It is important to understand the value and the 
limitations for each technique v before attempting to use them for making,;, 
decisions. , . > 

Certain cost concepts and analysis techniques discussed in this 
section must be performed to satisfy the requirements of specific 
directives. Where applicable, the .diseussion of cost analysis includes ft 
description of .how the costs are related to relevant directives. . 

C.6.1 COST CONCEPT S DEFINITION 

' "i ; — ~ 

The framework and procedures that are presented in' this 
appendix for developing costs are based upon the concept of full costing. 
That is, by defining; the full costs of a project in a detailed manner (i.e., 
multidimensional 'structure) it will be possible to derive cost 
classification^ from a single cost base. This is important in responding to 
directives, since the format and classification of this cost information 
may. vary. The cost concepts addressed below haye been the source of 
confusion in the application of cost information. While each concept is ~ . 
briefly discussed, a full definition can best be obtained, from financial and ; 
accounting reference material. "' % 

k o Direct/Indirect Costs - Costs may be classif ied as either 
V direct or indirect. The purpose of .identifying costs as 

direct or indirect is t6 assign all costs as precisely as * 
ppssible, to. the specific? product, service, customer or 
other cost objective tty|y»support. Some costs are. easily 
assigned directly to a product or service. For example, 
dthe cost of programmers that are dedicated to convert 
Specific application is a direct colt of that application. 
* ' The most common «6jct costs arefcfr labor and supplies. 
Other pp^kible direct costs include travel, purchased 
services .^d service center - charges fof .. items such as; 
; printing.^ ; ' I - . r\ , ■/* 

■. * Indirect Vdosts are costs ^that cannot be .^lrectly related 1 . 
- , \- ' t6 a product or servtee, it>r costs that afe 'insignificant pr 
> ; ■ .difficult to. measure* Examples' of items, that are often 

■\ 1 * y i - classified asjndirect costs are low cost supplies such as 
y. p'qper clips}? the labor Roosts .of receiving^, storing and 

■i \ distributing * materials and supplies; depreciation of 
'-.'../■' buildings arid general purpose equipment^ utilities; arid 

• general and ' administrative, r expense ' *for financial t ; 
• /• s , f , management and -other services that benefit the entire 

' ■'- . . - organization* Ind^reqt .co 4 3ts may still be assigned *to 
/ - y . specific cost objecftiv&s but the iassignment is through an 

I allpcation process. The "total indirect etost is spread 

arriong> all , cost objedlywfes according to criteria, s\ic]\ as 
nymbf t of people or to|i|| budget dollars., - . ' ^ 




Because separating fj|il costs atto direct and indirect 
> costs permits a careful assignment of costs to specific 
products or services, it is useful ibr conversion budgeting 
and project monitoring applications. A clear separation 
of cpsts assists managers who are responsible v for 
controlling resources and costs that are associated with* 
projects under their supervision. Awareness of the true 
cost df providing or receiving services permits managers 
to make informe4 decisions. 

* 

Constant/Current Dollars - The purchasing power of a 
dollar during one year is not; necessarily the same as the 
purchasing power of that dollar during some future year. 
Inflation ftieans that' more -dollars will be needed^ the 
future to "purchase the satpe. goods that .are purchased 
with less dollars today, the term "constant dollars" 
should be equated to (^constant purchasing power," that 
is, the price of *a resourc^ in terms of the purchasing 
power of a dollar in some base year. Current dollars 
represent the actual cost outlays in the year- they are 
expensed, and, show the effect of inflation on the 
constant dollar value/ / 

-Since both -^constant and current dollar estimates may be 
required during the project (e.g., constant dollars for 
economic analyses, / current | dollars for budgetary 
submissions), the software conversion, cost estimates 
should be developed in such a way as to support both 
requirements.. This is accomplished by estimating^ 
software conversion costs using* ' constant (base year)., 
dollars. By applying inflation -factors to these estimates, 
current dollar figures can tlrey Be determined for each 
future year. : - 

Inflation - Inflation is the rile in th$ general level of 
prices oyer time. Inflation complicates financial 
planning and cost analysis because it creates uncertainty 
about future prices. Current and past. rates of inflation 
may be measured by means of price indexes, which* are 
percentage cbmparisons of 4 the, prices of selected 
commodities' and .services between two periods of time. 
Futup^ rates of 'inflation can only be estimated. Once 
-the future inflation r^ie is estimated for the years of. a 
conversion project's life, the rate is applied to all future 
costs to adjust those costs for projected price increases. 
Because inflation affects the prices 1 of goods a^d 
services to be acquir^d'in the future, it i: an important 
c'd^nsiqe ration of full costing during any planning 6r 
estimating for items that are subject to price ehanges. 
Labor, supplies £nd utilities are examples of items that 
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may be affected by inflation; The total costs estimated 
for each year in the conversion project's life are adjusted 
by applying an annual inflation factor to each totaL 
Software conversion cost estimates should be able to 
reflect costs in actual dollar expenditures expected in 
each year of the project for budgetary purposes. 
Anticipated variations in the inflation rate should be 
addressed through sensitivity analysis. 

o Wash Costs - The cost of some items may be the same 
regardless of which of two or more alternative courses 
of action are selected. Although the amount of the cost 
may be important, it will not affect the outcome of a 
cost comparison among the alternatives. Such costs are 
referred to as wash costs. JFor example, if two options 
are for the government to purchase and operate certain 
equipment or to purchase the equipment and hire a 
contractor to operate it, the purchase cost of the 
equipment is a wash cost. It may be a major part of the 
■ . total project cost but the cost is the same for the two 

alternatives and will, therefore, not contribute more to 
the total cost of one alternative than the other. * 

Under a concept of full costing, all costs should be 
included whether a wash cost or not. This is because a. 
total cost is important/for budgeting decisions. Also, it 
is difficult to correctly identify a wash cost, since cost 
components may vary with the alternative selected. For 
example, the cost of management is often considered a 
wash cost; however, a software conversion in a distri- 
buted processing environment may require more task 
managers and higher travel and administrative costs than 
a .software cpnversion in a centralized processing 
environment. Another reason for including wash costs in 
the conversion costing methodology is that the scope of 
' the project may .change during conversion planning 
preparation. Costs which were correctly assumed to be 
a wash, now may have a cost impact on the project 
decisions. By addressing the full cost of a project, all 
cost areas would have been included, whether a wash 
cost or not. * 

C.6.2 ANALYSIS TECHNIQUES 

Cost analysis techniques are ' methods of using previously- 
defined and estimated cost data to make management decisions. The 
nature of the decision determines the techniques that are most 
appropriate for qach situation. The following are examples of analysis 
techniques that are valuable for management decisions. 

(• 
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o Present Value Analysis - E#esent value analysis is used to 
reflect the diminishing value, of money with. time. 
^ . • Jp resent, value analysis equates 'future costs to their 
present worth. Its : prfmary value is in the assessment of 
alternatives that have different cash flows and different 
durations. '* 

Sensitivity Analysis - Throughput' the ''costing process, 
various assumptiftns are made concerning the cost data 
used. These assumptions include inflation factors, cost 
estimation, workload, etc. A 5 part of the cost analysis 
process, .these, assumptions should be "evaluated to 
determine if changes in any one assumption will change 
the outcome. of the analysis.. 

Break-Even Analysis - Break-even analysis is used to 
study cost relationship between alternatives. 

Ratio Analysis - Ratio analysis* is a cost, -comparative 
process which may be used to compare, cost, data within 
an alternative, among alternatives or with fetandefrd cost 
data. * 

Risk Analysis - Risk analysis is a^ technique that uses 
probabilities to assess the potential for alternative 
outcomes. By assigning probabilities to each alternative 
and multiplying by the expected cost or outcome value 
of that alternative, a total, expected value can be 
determined. In* a software conversion proj^lt this 
technique is important in contingency planning to 
develop, a plan that assesses potentially harmful events 
\n a cost-effective manner. 

These techniques are intended only as examples, of the analysis 
methods that are available for use during the' project.- The use of these 
techniques, including their strengths, weaknesses and applicability to - 
project decisions can be obtained from a review of financial reference 
material It is important to remetaber, hoW^er, that the use of various 
techniques may yield conflicting results. It is improper to adopt a single 
analysis method for use in all applications. The analysis methods must be 
applied judiciously, with a knowledge of each methods limitations. 

C.7 APPLICATION OF THE COST DATA / 

The end objective of the conversion costing methodology is 
support of project management decisions. As illustrated in Figure C-l, 
the application* of software conversion cost information is directly related 
to the manno* in which costs have been defined using a dimensional costV 
structure. These dimensions allow the application of a single cost basis tb - 
a variety of project decisions and activities. In this section the 
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application of costs to specific conversion project decision^ and activities 
is summarized for each phase of the conversion. While some cost impact 
may be shown for every software conversion activity, this section is 
designed to highlight those tasks which are <most\ dependent upon the 
costing information. An overview of economic considerations is given in 
Figure C-5 and summarizes the cost detail contained^ in the body of the 
guides. . \ 

C.7.1 PROJECT INITIATION PHASE \ 

Prdjfect initiation is the phase in whic|i the requirement for a \ 
software conversion is determined. The major product of \this phase is a 
preliminary ' ^^feasibility study that includes the cost \estimates of 
conversion alternatives, a comparison and analysis of these^ alternatives 
based on cost and technical factors, and a recommendation of a proposed 
alternative. Accompanying this recommendation should be preliminary 
project plans that will accomplish the alternative courses of action.' Cost 
activities during this phase include: v \ % 

o Analyze the Project Characteristics and Develop the 
Unique Project Cost Structure - It is critical to develop 
the specific cost structure which is material to the 
project under investigation. This will require analysis of 
the basic characteristics and goals of the conversion 
project, and development of a specific- cost structure 
which will form the framework for future oost 
estimates, cost evaluation criteria, and cost tracking. 
This is a major activity which will requid£ careful 
planning to assure that the correct structure has been 
developed which will allow continuous use throughout the 
software conversion effort. \ 

o Establish a Preliminary Conversion Project Budget - The 
' cost structure should be used for budget preparation by 

identifying the estimated project costs for the following 
phases in tferms of various costs elements and functions. 
Also, the scheduling of these expenses should be 
established by assessing the priority (cost-effectiveness) 
of the project relative to other projects' under develop- 
* ment. 

o Estimate Project Resources - The project budget esti- 
mate and schedule can be matched to determine the 
availability and utilization of personnel skill categories 
• to be used. Adjustments, in personnel strength can be 
made to keep the project within budget and schedule, or 
to request additional funds. 

Iv ^ * 
Approval of the preliminary feasibility study signifies the completion of 
this phase. 
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C.7.2 CONVERSION REQUIREMENTS PHASE 

• During the conversion requirements phase, the conversion 
process is analyzed and methods and techniques are^ selected to 
accomplish the effort. The culmination of this phase is a software 
conversion study that includes an assessment of the current software 
environment, a program inventory, . and evaluation of contractor's 
assistance and a recommendation as' to the use of conversion tools. A 
specific costing activity during this phase is: 

o Project Pllnning and Staffing - Conversion ■ o cost 
* information can.be used to assist in project personnef 
planning by determining the best mix of project 
personnel apd determining the most gost-effective 
prpject strategy to follow. Cost trade offs between skill 
\ levels, person-hours required, and personnel expenses can 
L be evaluated for teach function during the projects While 
this impact on costs is important, it should be evaluated 
against management considerations such as expected 
turnover, skills back-up, critical staffing positions, 
employee development and the like. Furthermore, cost 
estimates, can be used to assist in evaluating alternative 
■»*' project execution strategies' sucflj 'as length of phases, use 
of contractors, and use of softwefke conversion tools. 
For each project management alternative considered, a 
<, cost estimate should be developed to assist in evaluating 
the impact of that approach. The final project manage- 
X\* ment approach selected should Abased upon the ldwest 
total overall cost to the organization, given the 
constraints of the organization, and the potential for 
satisfying the mission needs. * .. , ■' 

Approval of software conversion study marks >'the end of this phase and 
provides information that feeds the conversion planning phase. 

■ s \ 

C.7.3 CONVERSION PLANNING PHASE 

The conversion planning phase is used to develop the detailed 
task schedules and resource _ requirements needed to accomplish the 
conversion* At the completion of .these' activities a formdfts^onversion 
plan is submitted to upper management fftr approval to confinire with the 
project This formal conversion plan should include cost-related 
considerations such as a summary of the, conversion budget, a^description 
of the proposed cost-tracking mechanism, " and analysis of the cost- 
effectiveness of proposed conversion aids, and a justification for the use 
of contract persdnneL Specific costing activities during this phase 
include: 

o Prepare Action Plans - Cost information can be used in 
; * project planning and budgeting to estaSlish a project task 
. v schedule (e.g., PERT-COST and PERT-TIME) that allows 
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for the development of. the project in a cost-effective 
manner. Important considerations at this time should be 
the estimated deployment date relative to the expected* 
operational beneii^. The project duration reduction may 
increase costs as more overtime or contract employees 
are used. This increase in cost, however, may be 
justified if the project can become operational sooner, 
thereby decreasing operational costs. The cost structure 
provides the cqgf detail for project functions to allow Tor 
this evaluation. * 

Refine Budget - The budget application of cost 
information will aid ill identifying the costs for the 
current ph#se, updating project costs for subsequent 
phases, and submitting the A budget for the following 
year's effort. ( / 

' \ " " ' ■ • ' < 

Formalize Conversion Approach - This activity is the " 

further, refinement of the conversion plans developed in 
the previous phase. At this point, software conversion 
cost estimation models should be compared* against a 
task-by-task conversion plan to determine the adequacy 
of resources (quantity and skills) to complete the 
conversion within a suitable time-frame. At this time, 
the program manager should examine the alternative 
approaches which "are available to convert to the new 
system. These approaches - may include Complete 
redesign of the system, line-by-line translation, etc. The 
program manager will need to evaluate the most cost- 
effective conversion alternative based upon factors such 
as the age of the existing software (if appropriate), the 
remaining life of the system, and whether it currently 
satisfies user's requirements. Furthermore, the cost 
impact of the use" of outside .conversion services, 
ersonnel or tools should be evaluated using the cost 
information. 

Develop RFP and Evaluation Qrfteria - If external 
.support is to be acquired, the conversion costing 
methodology can be used to estimate costs, identify 
critical cost areas, ^and provide a cost evaluation 
Criterion that considers the impact in all relevant cost 
areas (price and other cost factors). Vendors should be 
required to submit cost data in' a format that can be 
included in the project's cost structure. The conversion 
costing structure should then be used to evaluate vendors 
based on total project costs that incorporate both direct 
vendor ^frarges and othpr agency project costs associated 
with using that vendor. This will require that the £Ost 
evaluation criteria used in the RFP be well documented 
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to allow evaluation of proposals based on lowest project 
cost Technical considerations, such as quality, can be 
mcye easily related to costs through the use of a total 
conversion costing methodology. There are certain 
service acquisition guidelines (FPMR, FPR, etc.)- which 
address- the -cos\, elements or functions which are 
allowable in making acquisition decisions. Since these 
may, be open to interpretation, it is recommended that 
Oversight organizations be contacted to approve tha^ cost 
] elements includecj in acquisition evaluation criteria. 

Approval of the conversion plan identifies the completion of the 
conversion planning phase. 

C.7.4 ' CONVERSION PREPARATION PHASE 

During this phase, the conversion manager accomplishes the 
activities required to assemble the personnel arid acquire the facilities 
and conversion tpols needed during the conversion effort Costing 
activities during this phase include: 

o Vendor Evaluation and Selection - Vendor selection 
, should be based on technical and cost considerations that 
account for the impact of a particular vendor's price arid 
other cost factors on the total cost of the project A 
detailed cost structure would enable the conversion 
costing methodology to ^ovide detailed Resource cost* 
information for each vendor' to assist in the validation of 
cost proposal and to assure an adequate quantity of 
resources have been proposed. For example, if support 
staff is included in the proposed, a detailed cost 
structure would identify the level of skills, person hours, 
and salary proposed by each v^pdor. In this way, . 
significant deviations between vendors may be 
addressed. Finally, the conversion costing methodology 
can be used, through sensitivity analysi^ to identify the 
► cost areas most critical >in the vendoi£§, proposal 

evaluation and selection. . These areas could then provide 
a basis for incentive clauses in the acquisition contracts. 

o Establish Deployment and Delivery Schedules - The 
timing^ of the deployment of the cohverted software and 
delivery of the proposed^Te^ources affect softwares 
inversion. •< There will iexist various approaches arid 
possible timetables for accomplishing deployment and 
installation. Each schedule may have cost impacts in 
terms of the potential net\]Denefits derived from the 
project The cost trade off objective involved in this 
scheduling effort should be the lowest total ^ost of the 
project - 
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o Develop Plans and Budgets - Through the use of 
historical project costs contained in> the conversipn 
costing methodology, the project budget, task schedule 
and resource assignments can be developed \for the 
conversion phase. Cost considerations such as the use of 
overtime or contract personnel, short-term rental of 
additional equipment r and space, and the impact of 
disrupted agency workload should be addressed > 

When preparations are complete the conversion phase begins. 

C.7.5 CONVERSION PHASE 

During this phase, the actual conversion of software fro\n the 
\ source » to the target environment is accomplished- This . phasdwill 

contribute to a significant amount of the total conversion cost but will 
have relatively few requirements for cost information other ^tj>en the 
fpllowing activity: 

o Evaluate Conversion Effort Against Conversion Plans - 
' The conversion costing methodology can, provide a 
detailed cost structure with which to accumulate actual 
cost data that can be used to compare actual cost 
performance data with historical estimates. In this way 
differences can be easily identified for further analysis, 
and the full cost impact on the project can be evaluated. ? 
This will require that the acceptance cost data be 
recorded consistent with the cost structure. 

/** 

Acceptance of the final converted system, fully documented and tested, 
mari^s the end of the conversion phase. % 

C.7.6 POST-CONVERSION PHASE 

The post-conversion phase ' is designed to provide an 
assessment of the completed project and prepare the organization for 
future software conversions. As such it is a continuous process with no , 
clearly defined end point The use of software conversion costs during 
this phase consists.of the fpllowing activities: 
/~ 

o Post-Conversion Analysis and Assessment - The analysis 
*\ of project performance should be performed as part of a 

post-implementation * audit. The colft/ersion costing 
methodology can assist in this validation by providing an 
historical cost basis and audit trail against which actual 
performance data can be measured. If actual system 
performance* significantly deviates from planned system 
performance, the conversion costing methodology' can 
help identify < the cost' areas and reasons for the 
differences. The function and product dimension of the % 
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cost structure can assist in projecting user's charges and 
evaluating the cost-effectiveness of changing user's 
requirements, and their impact on these user charges. 

r - 

Satisfy A-12 Requirements - OMB Circular A-12 requires, 
development of annual agency long-term plans to support 
budget submissions. Such plans project agency 
requirements for five years or longer. - Conversion 
costing methodokfgy is directly applicable to conversions 
considered in these plans. 

Agency budget Submissions • - Similar to A-12 ^ 
requirements, conversion costing methodology supports 
agency budget actions. 

- Satisfy A- n 6 Requirements - OMB Circular A-76 requires 
regular assessments of agency commercial-industrial 
type activities, to weigh the benefits of continual 
government operation against contractor operation. 
ADP services fall under the provision of/ A-^. 
Conversion costing methodology can be usefully ^applied 
to any agency A-76 studies conducted during the post- 
conversion phase. . , <? 

Satisfy A-109 Requirements - OMB Circular A-109 
requires cost analyses, to be performed for major system 
acquisitions. Large scale agency hardware replacements 
are frequently considered to fall under the provisions of 
OMB Circular A-109. The conversion costing 
methodology will directly support A-109 conversion cost 
assessments. 

Satisfy A-12 J. -Requirements - OMB Circular A-JL21 
prescribes the initiation of business-like procedures mat 
require agencies to account for the full cost of operating 
a DP facility* to allocate all costs to users according to 
services they receive, and to share excess DP capacity. 
JFhese costs, when developed, rarely include the costs of 
conversion and lead to * under resourcing conversion 
staffs. By maintaining the conversion costing 
methodology and accounting for cost incurred according 
to its structure throughout the life of the project, the 
cost information used in satisfying A-121 should be 
available. The conversion costing methodology provides 
the structure, through the use of organization and 
product dimensions, for allocation of conversion costs to 
users according to service provided. 
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SUMMARY . 

This appendix contains eleven case studies of software 
conversion projects at Federal agericies. Some projects had been 
completed; others were in planning' and execution stages when these 
studies were developed They provide additional insight into software 
conversion problems and illustrate that management attention is 
necessary to improve conversion efficiencies. Readers of this guide may 
find situations analogous' to their agency conversion environments aiti 
take action to preclude repeating mistakes made by others.- 
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AGENCY ^EXPERIENCE 

BACKGROUND 

* The organization discussed i&an element of a federal agency 
and -is 'a user of the agency's computer , system (approximately 10% of 
machine time). The organization had v§n in-house staff of programmers 
and analysts to develop and maintain il& automated information systems. 
The' AD P department of the agency acted as a service bureau to other 
departments and oqgariizations in the agency. 

/„•«■■ * 

because of saturation, the agency decided to upgrade its IBM 
360/65. A competitive procurement resulted in selection and installation 
of a UNIVAC 1100/43 system. Because of the results of the competitive 
procurement, the organization, as well as other users of the hardware 
executed a non-code compatible software conversion. 

✓ v. 

• /This conversion experience illustrates problems associated 
with siich a conversion as well as problems facing users of a large, 
"service-bureau 11 type of operation. 

THE CONVERSION 

Application programs on the IBM 360/65 were written in 
COBOL, PLL, FORTRAN, Assembly Language and RPG. Approximately 
75 percent *Wre written in the latter language. Little, if any, software 
documentation 1 existed for the IBM applications. There were many user 
enhancements which were pending but not incorporated in the old 
software because machine saturation precluded development and test 
time. f 

* *The decision to upgrade was made in the 1975-1976 time 
frame. Conversion planning started in mid-1977 and the target hardware 
was installed in mid 1978. !: , 

Soon after selection, UNIVAC made computer time available 
through Remote Job Entry (RJE) stations. This service was convenient, 
and facilitated the conversion. However, this service was not used to 
optimum advantage' in accomplishing early training and software 
conversion. The failure to use this resource to full advantage ultimately 
contributed tp conversion slippage. 

The organization decided to convert and redesign applications 
concurrently into a Data B6se Manffement Systems (DBMS), System 2000. 
It was .anticipated' that all applications could be converted before the IBM 
system was released* However,^this did not occur. Although the IBM 
hardware had been removed ih late 1980, as of January 1981 the 
conversion was still" !h progress and expected to take an additional year. 
The lo,ss of this hardware resulted in a line for line conversion of some old 
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applications without redesign and without parallel testing. Ninf" major 
DBMS applications were* active with approximately 400,000, 40-60 
character records. Four similar applications remained to be built. 

Information system users of the system were not sympathetic 
with conversion problems and continued to demand enhancements. No 
systems were frozen during conversion. Higher-level management was 
extremely interested and involved through hardware- acquisition and 
installation. Thereafter, there was little interest or backing for any 
processes which would have eased conversion, i.e., freezing development. 

Conversion was accomplished in-house. The conversion staff 
lost personnel without replacement due to* a hiring freeze. Summer hire 
students were used as programmers but their short employment period did 
not compensate for personnel shortfalls. In retrospect, it was recognized* 
that some contractual support should have been provided for personnel 
loss contingencies, even if not exercised. 

Before conversion started, code conversion was expected to be 
the most difficult processes In fact, code conversion was 
straightforward. However, old programs were heavily dependent on IBM 
utilities and the conversion staff encountered extreme problems in 
applying UNI VAC utilities, which differed considerably from those offered 
by IBM. 

The IBM systems programmers had detailed knowledge of the 
source system and were extremeJLy helpful to the organization's 
application programmers. Target systems programmers were new and 
lacked agency insight and experience. System programming support to 
the applications programmers dropped dramatically during conversion. 
Associated problems in debugging and adapting to the target software 
delayed conversion by approximately six months and extended parallel 
testing. 

Conversion costs were not tracked but were estimated to have 
consumed 3 person-years of effort 

MANAGEMENT LESSONS v 

In summary, lack of planning led to an underestimation of 
conversion resources and precluded early training and conversion on the 
RJE station. Conversion managers did not anticipate the need to handle 
unforeseen problems such as differences in software utilities and 
inexperienced systems programmers. These ^^roblems were compounded 
by not freezing development and incorporating new user enhancements in 
conjunction with the conversion. 
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AGENCY 2 EXPERIENCE 
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The following is a case history of 6 software conversion 
experience that took place from 1974 to 1980 at a federal agency. , 

BACKGROUND \ 

the agency operates k large centralized service bureau 
computer .system serving various) agency departments and other 
government agencies. Saturation caused the agency to conveft from an 
IBM 360/65 to twoUBM 37<m£*% and then to an AMDAHL in 1979. 
Approximately 55 pe^enj>dfthe code was FORTRAN, 45 percent PL 1 , 
and 5 percent COBOL, in every case, migration of application programs 
was to code-compatible machines. However, there were conversion 
problems in converting to the AMDAHL that are useful as learning 
vehicles, particularly from the perspective of a service bureau operation. 

THE CONVERSION 

The agency allowed one year for planning purposes but 
considered that two years would have been better. The biggest problem in 
conversion planning was obtaining user's input Neither users, nor anyone 
else, knew the status of all the available programs. Purging outdated 
code, old test code and duplicate programs was a difficult exercise. 
Although users were charged a pro-rata fee for service and machine time, 
resources were not applied to storage. Hence there was no incentive to 
cause users to remove unwanted code or data from the inventory. 

One person was assigned to the Conversion full-time and 
served as project manager. While the coAersion was viewed as 
successful, it was considered that better coordination and interaction with 
users and managers could have been effected if more people had been 
dedicated to project management activities. Such assignment was 
precluded due to the agency charging scheme. User's charges were based 
on normal, day-to-day operating costs such as machine use, line costs, 
utilities, and programming services. There was no built-in overhead to 
cover project management personnel required for software conversion. 
Continuous negotiations had to be conducted with users to provide the 
extraordinary project management resources associated with the 
conversion. Essentially project management resources were understaffed. 

Adequate documentation on application programs was 
unavailable. This condition was due in part to the nationwide spread of 
users who were responsible for developing their own application programs. 
Additionally, users continued to develop and enhance systems throughout 
the conversion. These factors, coupled with the outdated code in the 
inventory, caused difficulties in developing software conversion 
specifications. 
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x High level management was primarily interested in hardware 
procurement and installation. The next level of management (functional 
information system users) were v primarily interested in keeping 
applications under development \ 

Some planning is now in process for the nrat conversion. \ The 
use of software standards is being stressed along wuh documentation. 
Given the limited control the processing centerjfthas over user's 
applications, the achievement of acceptable use of software standards and 
documentation was questionable. 

MANAGEMENT LESSONS 

In summary, there were problems .with high level management 
involvement, user's support, program specifications, detailed planning and 
project management resourcing. Had these problems existed in a non- 
code-compatible environment, serious problems would probably have 
resulted. The selection of a code-compatible machine' resulted in the 
conversion being accomplished in an acceptable time. However, the 
conditions that could have caused problems for a non code-compatible 
conversion still existed. 
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AGENCY 3 EXPERIENCE ' - . 

BACKGROUND ^ 

The ag€ncy is responsible for management of world-wide cargo 
traffic. A significant functional area involves port^cargo operatibns. For 
some time port cargo operations were supported by a management 
information system (MB). * 

Dual Burroughs 5500 computers were operating at two area 
headquarters locations, one on the East Coast, and the other on the West 
Coast. The B5500 computers were linked to IBM 360/20 terminals located 
at offices at various ports (e.g. Seattle, New Orleans) The MIS handled 
movement control, manifests, container transhipments, and other traffic 
management applications generally oriented to export cai^go, as well as 
retrograde cargo. „ 

Growth in cargo movement administration had saturated the 
B5500 computers. Given the age of these computers and the IBM 360/20 
remote job entry (RJE) terminals, continued reliance on this equipment 
posed a risk to system reliability. Software enhancements were difficult 
to introduce, particularly on-line applications. While the MIS was 
originally a standard batch-oriented system, the B5500 computers would 
support remote terminals. Differences in the degree of saturation at each 
area headquarters had resulted in some capability for on-line applications 
on the West Coast. However, all applications were batch on the East 
Coast, due to the inability of the B5500 to process the higher cargo 
volumes in an on-line mode. Because of these conditions, in the mid 
197 0*s, the organization decided to upgrade the system with the following 
objectives: 

o Modern equipment, 

o On-£ine applications, « 

o Sufficient processing capacity to handle extraordinary 
cargo movements loads, 

o Improved redundancy and reliability, 

o Standard applications on both coasts, 

o Stand alone capability at various ports. 

THE CONVERSION 

Pkmning started in the summer of 1978. Honeywell Level 6 
computers were selected as the target hardware. The initial planning 
resulted in a systems concept which was approved in October 1978. The 
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Concept called for replacement of the B5500 computers as soon as 
possible with dua^ Honeywell Level 6 computers at the two area 
headquarters, and rep'acement of the IBM 360/20 terminals with single 
Honeywell Level 6 computers The concept also provided for transfer of 
some of the non-time sensitive, historical, high-volume applications to the 
agepcy headquarters for processing on a HIS 6060 mainframe which was 
already in place* The combination of ^modern hardware and revised 
application processing covered all system-upjgrade objectives. 

\ After the concept had been approved, detailed planning 
commenced ip early 1979 and continued for six to nine months Thorough 
planning, early in the project, was recognized as necessary to successfully 
execute the project. This planning was accomplished by a management 
team which was organized tor the purpose. Planning was a continuing 
function, ongoing m id way ' through the conversion, and was expected to 
continued until the conversion was completed. There were always 
4 unforeseen events which had to be compensated for and wlych required 
revised plkns. - 

Automated (PERT) planning tools, available through 
Honeywell, were tried without success. Planners felt that the extra 
effort to enter all of the project data did not result in automated planning 
aids which were any better than those manually-produced. 

PROJECT MANAGEMENT ^ / 

The management team was essentially a project management 
effort. Originally it was envisioned that the team could be dissolved after 
it had planned the schedule and identified all activities and actions which 
1 had to be accomplished (e.g., - equipment selection and acquisition, 
software conversion, communications specifications, and training). The 
team was temporarily dissolved, but it soon became apparent that the 
project was losing coordination and direction. Formal project 
management was reconstituted on a permanent basis before any adverse 
developments occurred. 

SOFTWARE 

There were over 900 source programs to convert Most were 
written in COBOL-64 and 68 except for a few FORTRAN applications. 
No new user enhancements were introduced during the conversion. The 
conversion was essentially a line for line conversion modified by introduc- 
tion of some Honeywell input-output and transaction handler routines used 
- as a matter of expediency. An automated Honeywell tool was used to 
' convert B5500 applications to be transferred to the HIS 6060 mainframe. 
This tool was modified in-house to convert the target software to be 
placed on HIS Level 6 computers. New enhancements and redesigns, 
primarily on-line applications, were scheduled for development after the 
conversion. 



209 

-p , r 186 



The. old system documentation was often incomplete, 

causing problems in planning and in developing conversion specifications. 
The new system will be completely documented using government 
standards. Documentation was ongoing concurrent . with software 
conversion. '*'■.» 

MANAGEMENT AND USERS INVOLVEMENT , i 

Top agency executives backed the prbject from its inception. 
Management understood the operational advantages of a speedy 
conversion and. the problems associated with the conversion This 
management support was also conducive to good functional user's 
cooperation. The project management interacted regularly at all user 
and management levels to keep these parties appraised of progress and 
involved in meeting requirements. , . * , 

* * 

FUNDING AND RESOURCES - 

Because the project was well planned in the beginning, 
adequate resources were identified, programmed and budgeted to support 
the equipment, communication, site preparation* and training.- The 
software conversion was accomplished with in-house resources. 

STATUS ' * , , • x 

Preparation for conversion started in the fall of 1979. Actions 
during this phase included assembling and modifying the software 
conversion tools, "site preparation ahd installation of target computers. 
Conversion actually started in early 1980; All conversion was to be 
completed by late 1981. Individual subsystems would undergo parallel 
testing until all users and managers were satisfied. Parallel testing 
operations would be supported by existingifresources. As of January 1981, 
the project was on schedule. This condition was primarily due to good 
planning, active project management and user and management 
involvement and support. The source computers were scheduled for 
release in the fall of 1981 at Western Area and the spring of 1982 at 
Eastern Area. 

MANAGEMENT LESSONS 

■v 

This case history illustrates that the advantages of achieving 
high level management and functional user's support, development 
freezing, good planning, and adequate project management can result in 
an efficient software conversion accomplished on time and within budget 
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AGENCY 4 EXPERIENCE ' 

$ ... 

BACKGROUND > 

* The federal agency interviewed was ^sponsible for bi-monthly 
mailings of computer output, and had definite schedule restrictions. The 
agency was running its systems on old UNIVAC/Spectra hardware. During 
the 1975 time-frame, management decided that the system was saturated 
and further ^enhanc«ments of the current system "would no longer be 
effective. "A Honeywell computer. was selected as the target hardware. 

The Spectra was running over 20 systems consisting of 270,000 
lines of assembler code, and 30,000 lines of COBOL. Conversion was to 
be to* COBOL/68. The*agency had adequately documented its system 
according to FTPS PUB-38. 

THE CONVERSION , 

A conversion project team with 19 programmers/analysts was 
organized. Tasks included conversion, maintenance, and operations with 
50 percent effort on conversion and 50 percent on maintenance. 

One special consideration and concern in this project was the 
conversion of compressed assembler code with over 600 file formats and 
100 different record types. Because record control bits were used to 
identify field length and absence of data, the conversion from EBCDIC to 
Honeywell BCD was of critical concern. 

Contractor services for conversion assistance was for a cost 
plus fixed fee (CPFF) contract at a cost of $1.7 million. Assembler 
Language to COBOL/68 automated tools * were developed by the 
contractor. These tools were fairly successful but manual coding for 
special extensions was still required. Another tool was used to compress 
data files. > 

Of the twenty systems to be converted the ten smallest were 
converted first. During their conversion, significant problems became 
apparent Some converted programs were far less efficient on the target 
hardware than the source hardware. Midway through the conversion 
effort, target hardware was changed to an IBM 3231, and the remaining 10" 
systems were converted to this hardware The IBM software was 
compatible with that of the source software and conversion was much 
simpler. • 

Prior to the conversion, the agency had provided back-up 
services with a time-sharing firm in case conversion hardware facilities 
went down. The agency was also prepared to keep and maintain the old 
Spectra hardware -Until all systems were converted 
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MANAGEMENT LESSONS , 

While adeqjrfite planning was spent in converting master files 
and development of test data, little effort was expended in developing and 
analyzing benchmark ^criteria. This was exemplified by one system's 14 
hour run time on Honeywell target hardware compared to 55 minutes on 
the IBM target hardware.— r 

Software conversion managers did not participate in hardware 
procurement decisions In both instances (conversion to Honeywell and to 
the IBM), the software manager was notified after the hardware was 
procured. This left inadequate time for planning. The software project 
manager was also unable to prevent users from ordering enhancements. 
The conversion team was able to deal with this, but the project would 
have been easier, had software been frozen. Upper management did 
intercede, at times, when user's requests were unduly affecting the 
conversion effort. 

Financial planning was also inadequate. Though the contractor 
came within budget, there would have been a cost-overrun had the target 
hardware riot been changed to a code-compatibl^configuration. 



AGENCY 5 EXPERIENCE 



BACKGROUND 

^ ^ * The organization interviewed was responsible for maintaining 

up-to-date information on world-wide activities, and distributing this 
information to field offices around the world. This organization was one 
element of many within the agency. 

The information files, which constituted the bulk of the 
automated effort, were extensions of applications that had been 
maintained for many years on punch card accounting machines. These 
files were migrated to an IBM "60/40, which was acquired in 1969, and 
placed on & DBMS. 

In 1973, the vendor supporting the DBMS cancelled support 
This resulted in a decision to convert to another DBMS. Conversion was 
to be completed within 6 months. 



Situation at^Project Initiation 

■L 

o Batch applications,- approximately 75 percent of a 
sequential workload, were running on an IBM 360/40 3 
shifts a day, 7 days a week; 

o No programmers, users or analysts were trained in the * 
new DBMS. / 

o There was a programmer and analyst staff of 18. / 

o The staff, which had recent conversion experience 
* before was still in place. 

o High-level management agreed to halt all enhancements 
to existing applications This caused user's support of 
the project, at least to the extent that they couldn't 
pressure the ADP staff tcycontinue enhacements and new 
Y developments. 

THE CONVERSION ♦ 

A straight redesign conversion was planned without 
incorporation of new user's enhancements. 

A project management tearn was established. The supervisor 
of the analysis and prpgranrhming section was the team-head, assisted full- 
time by the lead systems analyst. The most competent developmental and 
maintenance programmers (approximately four) were added to the team 
full-time. One input-output control technician was also added full-time. 



' The complete lack of any staff trained in the new DBMSprjb a 
serious problem. This problem' was compounded by the lack of ixperi&nce 
in newly-trained r programmers, and the short project deadline. 
Coordination with a mobile training team revealed locations where new 
DBMS training was scheduled. Coordination with organizations scheduled 
to receive new DBMS training produced a few slots to train project team 
members as early as possible. The training team also cooperated by 
adjusting their schedule to provide on-site analyst, programmer and user 
training to most of the remaining conversion team approximately one 
month afte* project's initiation. This was sufficient to accomplish the N 
conversion. 

No contractor's y&sistance was used. The most complex 
system was chosen for the initial conversion -It was assumed that if the 
project management team could convert that application, the remaining 
applications would be problem free This approach produced successful 
results. 

Freezing new user's enhancements and system development 
provided enough computer time for training and conversion except for two 
two-week pericWs late in the conversion process. Arrangements were 
made with back-up computer facilities to provide processing time during 
those two week periods. Small teams of . computer operators, 
maintenance programmers and a system programmer were dispatched to 
run production reports and applications. 

A flhe conclusion of the six-month period, the conversion was 
complete. However, all converted applications had not processed in 
parallel for a tW-month pferiod to allow debugging and assure quality 
controL Parallel testing operations continued for two additional months. 
Moreover, while documentation was an ongoing effort during conversion, 
full^ets of systems documentation were not completed until 
approximately four months after the conversion effort 

Unbudgeted conversion costs were mostly absorbed by 
cancelling or limiting projected travel and carefully monitoring operating 
costs for the remainder of the fiscal year. A mid-year request for 
shortfall-funding provided the additional funds necessary to cover alf 
costs. 

MANAGEMENT LESSONS 

This cbnversion, which was essentially accomplished on time, 
received high-level management support, and benefited from the freezing 
of new enhancements and development Full-time project management 
and an experienced staff had the insight and authority to overcome 
problems associated with a short conversion deadline and inadequate 
training. * • . , 
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AGENCY 6 EXPERIENCE 



BACKGROUND , 

In 1973, the agency developed 15 administrative data base 
management system applications supporting agency training. These 
applications were run at night as batch on a^ Honeywell (JUS) 635 
computer, the daytime hours being primarily reserved for on-line student 
use of the hardware system. There was no requirement for student access" 
to the administrative applications. However, the staff and faculty did 
require access at times during the day. 

J Besides the training-related administrative systems, there 
were approximately 300 various agency installation-unique COBOL 
programs which were processed, as required; at night oh the HIS 635. 

By 1974, the/ on-line demands of all users exceeded the 
capacity ^>f the HIS 635/ system. Efforts to upgrade, sole source, were 
denied and competitive hardware procurement and software conversion 
contracts were pursued. To resolve saturation problems the agency was 
permitted to upgrade the hardware to an HIS 6080 System as an interim 
measure pending completion of the competitive procurement. 

THE CONVERSION 

UNIVAC won^ both the hardware and training-related 
administrative application conversion contracts. A UNtVAC il00/ll was 
selected to process the COBOL and administrative applications. A 
UNIVAC 1100/12 was selected to provide time sharing service to the 
student body. Separate from UNIVAC, another contractor was awarded 
the contract to convert the agency unique COBOL prbgrams. 

It was decided to redesign the administrative ^ DBMS 
applications to another DBMS offered by UNIVAC and to convert the 
COBOL programs line by line. 

There were problems with development of the UNIVAC DBMS 
software conversion specifications. Users were not interested in 
collaborating in the specification definition effort They were relatively 
satisfied with the existing DBMS applications. Since the input and output 
would remain essentially unchanged, the users were not inplined to 
emphasize to the conversion planners the subtle but important/insights or 
considerations relating to timing of reports or relationships of certain 
reports to others. While these relationships were probably understood by 
the in-house team that developed the specifications, they were not 
adequately stressed, and ultimately not comprehended by the contractor. 
Futhermore, the original software documentation was outdated or 
nonexistent. This condition contributed to conversion specification 
inadequacies. 
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Conversion from one major DBMS to another resulted in an 
extremely complex software design effort The complexities of the 
project, when coupled with specification shortfalls, resulted in disputes 
with* the contractor, project slippage and generated considerable 
/ unarlticipated involvement in the conversion process by the in-house staff 
fj2£og^ammers and analysts. 



0\ The agency insisted that the UNIVAC contractor develop 

complete software documentation based on FIPS Publication 38. The 
contractor sought release from this requirement Disagreement over 
' contractual conditions relating to documentation requirements and 
specification shortfalls^ resulted in slippage of the conversion effort 
approximately^ months past release of the HIS 6080. This condition 
precluded parallel testing of some applications. 

Disagreement over contractual levels of effort with the 
second conversion contractor over a lack of COBOL programs 
documentation led to disputes which resulted in contractor conversion of 
approximately 90 percent, rather than all of the software. Twenty-four, 
on/" 10 percent of the applications, were converted in-house. The 
contractor did not provide any documentation. The agency intended to 
write the documentations-house but recognized that in reality some or 
all of the program documentation would never be developed. 

It was estimated that all software conversions could have been 
accomplished in-house for the saijje effort spent in resolving all 
con tractual Software conversion issues!^! 

Analyst and programmer -training on the new system was 
considered sufficient but was conducted too early. Maintenance 
programmers lost their technical edge due to too much elapsed time 
between training and delivery of the contractually-developed DBMS 
software for their maintenance. 

4 ' 

Formal processes were established and adhered to regarding 
review of contractor performance and recording user acceptance of 
converted applications. These processes assisted in conversion by 
improving understanding, reducing slippage and monitoring costs. 

Full-time project management had not been exercised in the 
> p re-conversion phases and resulted in planning short falls (e.g., inadequate 
software specifications and training). To remedy this the software 
conversion process operated under the project manager concept. This was 
considered invaluable in resolving unanticipated issues. It was also 
considered essential that a contractor have a full-time project manager 
throughout the project. This had been the case until the contract was 
extended to compensate for slippage. At that time, the contractor 

' project managers position was abolished in an attempt to reduce costs. 

- Thereafter, internal contractor coordination and management problems 
developed and adversely impacted productivity. 
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MANAGEMENT LESSONS 

This case history illustrates the need to have software well 
documented. Documentation facilitates conversion planning, development 
of software specifications and contractual statements of work. The need 
to maintain full-time project management throughout a conversion was 
also shown. Management.recognized the need for software documentation 
but experienced problems with the contractors who resisted deliverv of 
documentation. - V 
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AGENC Y 7 EXPERIENCE 



BACKGROUND ■ • . • 

... ■■ h i — , i • -.ii 

The agency- is responsible for the regulation of a major 
industry. To administer the programs necessary for compliance with its 
regulatory responsibility, the* agency utilizes the , services of its data 
processing division to track various equipment, licenses, and applications, 
monitor violations, and other administrative functions such as payroll and 
personnel. 

Aging hardware and systems growth resulted in, a conversion 
from a UNIVAC 3 to a Hotffeywell 6023 computer system. ' Conversion 
consisted of some 30 systems encompassing 260 programs. written in SALT 
.(assembler) and translated into COBOL. 

' i I • ■ A 

Planning for the conversion began in late 1973. By that time 
replacement parts for the UNIVAC 3 had become difficult to obtain and 
often requiredcannabilizing other UNIVAC 3 systems. Th6 workload h&d 
reached a point jthat the agency rented time on a UNIVAC 1I08T to handle, 
its UNIVAC 3 overflow. Tire agency developed specifications for its 
conversion after holding discussions with conversion specialists. Separate 
hardware and software conversion RFPs were prepared, and released in 
19?5. Honeywell won the hardware selection' while another contractor 
was awarded the software conversion project. > 

/THE CONVERSION 

Under the terms of the software RFP the agency 'was to 
provide systejri documentation, programs, test data, and machine time to 
contractors." The specifications, however, allowed the contractor/ to 
request virtu&lly unlimited levels of detailed documentation, and that test 
data be , in contractor specified format. These conditions a placed 
-unanticipated ^workloads on the conversion project team - Program 
acceptance was based upon successful execution of 90 percent of code. 
However, no . performance specifications Were required. As a result, 
processing that had ■previously required tw.o .shifts on the UNIVAC 
required three shifts q^^^ This condition indicated that/the 

software was inefficient in design. , ' * ■ V 

v Some ^2,00,0 d^ta .fries/ ranging from 2,000 records to 7- n 

million records pe'r hie w^e reqtrfred to be % converted.. To convert thesfe 
files,* the agency had .to temporarily acquire, a. minicomputer at an 
additional cost of $25,000. A ^bit to '\ byte^V fbrrnat change* had to be 
accomplished because of software .differences between; soured ahdftarget 
systems and caused considerable problems for the agency. 

»•.*. ■* . •-■ 

The conversion staff consisted/of seven full-time and twd: 
part-time personnel who handled a the data cor\v,ersion effort along with 

/ 
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two full-time (on-site) contractor personnel for 12 months. The number 
of contractor personnel working off-site was unknown. What was initially 
estimated as a 9-12 month conversion effort actually required two years 
(in addition to one year spent in planning and procurement) for a total of 
21 man-years" of effort. Both the schedule and budget ($1 million) were 
overrun. 

Because of continuing growth, the agency again upgraded to a 
Honeywell 6640 in 1978, and in late 1979 upgraded tp a Honeywell 6660. 
These migrations, being code-compatible, were accomplished with 
negligible problems. 7 

* , 

• While existing systems ^and operations documentation was 
adequate, the contractor was required only to document the operational 
procedures (run manuals) for the H6023. System/program documentation 
was left up to the agency. 

There were no ongoing plans for future conversions although 
the agency had upgraded hardware twice since the conversion to the 
Honeywell 6023. 

MANAGEMENT LESSONS 

The conversion and budget overrun were indicative of poor 
initial planning. Also, the software conversion contract was constructed 
to the cori tractor's advantage which adversely impacted the conversion 
staff efforts. This resulted in bss of project management control over 
the contractor, produced programs with exceptional run times (indicative 
of potfhwsoftware design), and caused delivery of inadequate software 
documentation 
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agency 8 experience 



The following is a case history of a software conversion 
experience at a federal agency that started in late 1976 and was still 
ongoing in February, 1981. 

BACKGROUND 

The agency was heavily involved in simulation and modelling. 
There werfe approximately twenty major Models running on a UNIVAC 
1108 using EXEC 8, Level 33. The models were large-scale, mostly 
written in FORTRAN, with some COBOL used The twenty major models 
consisted of approximately 200,000 lines of code in FORTRAN and 50,000 
lines in COBOL. Other models and systems doubled the lines of code to 
approximately one-half million. 

In late 1976, ADP personnel determined that the system was 
saturated; models were taking too long to run. A hardware RFP was 
released in February 1979. UNIVAC won and a UNIVAC 1182 w^s 
installed. The source and target system machines were expected to run in 
parallel for approximately six months. The RFP required a pre- 
installation test facility nine (9) months before the new mainframe was 
installed. 

THE CONVERSION 

Prior to releasing the RFP, all models were scanned and code 
was analyzed for vendor specific extensions. Problems were noted in two 
areas: 

t L 
o Word size, 

o Representation of character type data. 

It was decided that software conversion would be done by in- 
house personnel Contractors would require too long to familiarize 
themselves with the models Agency functional users were also the 
programmers, were ,the most familiar with their own models, ^nd 
considered best able to perform the conversion. Additionally, 
documentation was inadequate and outdated, adding to the difficulties of 
indoctrinating contractors on mechanisms of the models. Automated 
tools were also examined but determined to be ineffective.- 

A detailed software conversion requirements study was not 
performed. In-house personnel were expected to handle the conversion in 
addition to their regular duties; L no specific planning or thought was 
accomplished to address the difficulties associated with this option. 
Software conversion was thought simple and no major problems were 
expected. A project team was not organized, and no cost estimation was 
performed. 
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The conversion itself proved to be straight forward because a 
code-compatible machine was selected. UNIVAC was the only 
respondent Operating systems were very similar and few problems were 
encountered during the conversion. However, management personnel did 
not plan adequately for site preparation. Because of delays in getting 
GSA approval for site preparation, the 1182 had to be installed in a 
UNIVAC facility. GSA, as of February 1981, had yet to approve the site 
preparation. 

MANAGEMENT LESSONS 

The agency was extremely fortunate in obtaining a code- 
compatible machine In spite of a previous conversion experience that 
had proven very difficult, conversion requirements were relegated to a 
minor role. No planning or cost estimation was performed. 

v.. 

Also, the lack of adequate model documentation would have 
impacted on conversion if a non code-compatible machine had been 
selected. The models, maintained by users who understood the code and 
model scheme, contain modifications that were rarely documented. 
Despite the potential conversion problems posed by this lack of 
documentation, prograip documentation was not being pursued: 
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AGENCY 9 EXPERIENCE 



BACKGROUND 

This agency was in the planning and procurement stage of a 
software conversion to meet increased mission needs and requirements. 
Their applications were being processed on a variety of hardware 
configurations within the agency, consisting of a Honeywell 635, two IBM 
3032s, a Honeywell 6000 and a Honeywell 6060. In addition, a DEC2020 
and five PDP ll/70s were included in their hardware inventory. 

PLANNING 

Although the planning and procurement process had been on- 
going for two and a half years,,the RFP has not yet been awarded; thus 
target hardware was still unknown as of February 1981. 

It was estimated that the conversion effort itself would take 
two years and that the total conversion process including planning and 
procurement, would last four and a half to five years. 

Various off-the-shelf automated tools were currently being 
evaluated to handle the common compiler driver language types. For 
example, plans called for automatically converting COBOL/68 to the 
more efficient COBOL/74. In addition to COBOL their basic software 
packages in use included FORTRAN, PL/1, SIMSCRIPT, GYPSIE 
(graphics), SPSS, as well as a variety of ad hoc-query/update routines. 

STAFFING S~ 

Although the bUlk of the conversion was to be accomplished by 
in-house personnel, provisions called for a one-year task order type 
contract to be awarded for assistance as needed, during the conversion, 
was projected that one third of the conversion would be accomplished by 
the use of automated tools, one third through recoding, and the remaining 
one third would require some degree of redesign. 

There were 675 people assigned to the agency data center, 600 
of whom were programmers. Approximately 100 project officers, and 
their staffs would be responsible for actually accomplishing the 
conversion. Each project officer would be assigned responsibility for one 
or more systems. Reporting to each project officer would be a variety of 
programmers and analysts. It was projected that 200 people would be 
involved at any one time in conversion duties. Two million dollars was 
budgeted for an estimated 400 man-year effort 
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MANAGEMENT LESSONS OR OBSERVATIONS 



For a conversion of this magnitude, it was planned 
significantly far enough in advance to allow adequate time for staffing, 
identifying, and evaluating activities. However, two major shortfalls 
were observed: 

(1) The budget of $2 million appeared extremely low. A 
more realistic bucjget was estimated at $6 - 9 million. 

(2) User and system documentation was not satisfactory. 
Although standard^ were being examined, this critical area had not been 
stressed. Lack 'of acceptable documentation would most pcpbably 
complicate future conversion efforts. 
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BACKGROUND 



AGENCY 10 EXPERIENCE 



The agency interviewed was responsible for maintaining an 
inventory of equipment and supplies at locations throughout the world 
The agency maintained statistics on equipment failure, and adjusted the 
maintenance schedule as indicated by these statistics. Programs were 
written in COBOL and Assembler, and the data base management system 
was TOTAL 7. The primary environment was in on-line/real time mode, 

r 

Management decided to upgrade the system in late 1977, and 
plans were made to release an RFP to procure new equipment. The 
source machines were IBM 360/40's. IBM 4331 machines were selected as 
replacements. + 

THE CONVERSION 

Approximately two years of planning was performed prior to 
release of the Requests for Proposals. During this planning phase, though 
target hardware was unknown, the following activities were performed: 

A project management team was assembled, 

Programs were inventoried, 

Schedules and milestones were determined, 

Management hierarchy was developed, 

It was determined that conversion would be performed 
in-house by users (programmers and functional users 
were the same), 

Formal test procedures were developed. 

The conversion went fairly smoothly. Software was not 
completely frozen, however, and some incorporation of new user 
enhancements was accomplished. Some problems were encountered with 
vendor extensions operating on the 360/40's. Weekly meetings, held with 
the project management team and programmers, kept all participants 
aware of problems that other personnel encountered. 

At the conclusion of the conversion, the agency initiated a 
system to examine both the positive and negative aspects of the 
conversion in the interests of facilitating future conversion efforts. 



o 
o 
o 
o 
o 

o 
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MANAGEMENT LESSONS 



The major shortfall noted in this conversion effort was a lack 



of cost analysis and accounting. Though progress was tracked, costs were 
not Thus, the agency had no detailed knowledge of the actual conversion 
costs to use in planning and estimating future conversions. 

Planning activities appeared to be adequate and these plans 
were implemented during the conversion.. The following activities were 
cited as being beneficial to the effort: 



o Developing bar charts depicting milestones; these were 
easy to follow. 

o Developing and irrolementing a conversion-reporting and 
management hierarchy; personnel knew who to report to. 

o Holding regular meetings; information was disseminated 
to the staff. 

o Availability of adequate documentation. 
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* AGENCY 11 EXPERIENCE 



BACKGROUND 

In June 1981, a federal agency was in the planning and 
preparation stage of a software conversion. Due to problems with the 
aging CDC 3300 computer, the agency was preparing to convert 
applications to a AMDAHL 470V/7A computer. 

PLANNING AND PREPARATION 

The agency planned to convert 600 programs estimated at 
700,000 lines of code encompassing approximately 24 major applications. 
All applications were business-oriented in nature. Processing was batch 
but was expected to shift toward some on-line DBMS with the recent 
acquisition of IDMS on the AMDAHL. 

Due to hiring freezes and budget constraints, the ADP st&ff 
was short of six full-time programmer/analysts. Because of this 
manpower shortage the agency was conducting preliminary negotiations 
for contractor's conversion assistance. The contractor would have 
responsibility for section and/or development of any automated tools to 
be used. 

The user's community, consisting of 14 major functional users 
had been notified of the upcoming conversion. * Functional users were 
cooperative and constructive but plans did not anticipate a heavy user 
involvement in the conversion. Current plans called for off-site unit 
testing at another computer facility, with system and parallel testing 
being conducted on the AMDAHL. 

The conversion manager was not assigned full-time and had to 
direct not only the conversion project bat also conduct normally assigned 
duties as welL 

' The team had no prior conversion experience, and as a result, 
no comprehensive conversion -plan was developed. Although the planning 
process was still being formulated, the entire scope of the planning effort 
had not been determined. It was estimated the conversion effort, 
excluding planning, would take 18 months, and that the total conversion 
process, including planning and preparation, would take 2 and a half years. 

MANAGEMENT OBSERVATIONS . 

Considering the scope of this conversion, this agency did 
reasonably well in their planning, preparation and identification of many 
potential conversion problem areas. They assigned conversion priorities. 
They recognized the importance of freezing software development and 
maintenance but were also aware that the demands and mandates of users 
would likely preclude any total freeze, they, therefore, instituted change 
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control procedures to facilitate conversion with new user enhancements 
where freezing could not be accommodated. Moreover, their lack of 
conversion experience forced them to recognize the need for* contractors 
assistance. However, lack of conversion experience coupled with a non 
full-time conversion manager resulted in some problem areas being 
overlooked Among these were: 

o Selection of conversion technique(s) still remained to be 
resolved (i.e., determining the programs that lend 
themselves to translation by automated tools, recoding, 
or that will require a complete redesign; particularly in 
view of the recent acquisition of IDMS). 

o Data (Communications and its attendant requirements 
with agency RJE stations were completely overlooked. 1 

o Adequate training, critical to a smooth and successful 
conversion, especially when converting to non code- 
compatible hardware, had not been planned. 

o No overall top management^onversion plaqj had been 
developed. Rather, planning had bedn fragmented. 

o No contingency planning had been developed (e.g., 
determining how the agency would cope with losses or 
transfers in team and staff personnel). 
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ERIC 



Activity 



Application Programs 



Application System , 



Distinct software conversion work that is 
accomplished within a phase; examples of 
activities would ' be organizing a software 
conversion team, budgeting for software 
conversion. 

* '■ r\ 

Programs developed for functional users; to be 
differentiated from system (operating) programs. 

One or more applications programs which together 
form an information system for an agency. 
Examples are pajtfoll, personnel, supply inventory, 
equipment maintenance. 



Automated Tool 



Software to aid in software conversion by 
converting some or all of the old source software 
to the target software. An automated tool could 
also be used in an- intermediate step, e.g., 
converting assembly language to COBOL on a 
source machine for subsequent conversion to 
COBOL on a target machine. 



Data File 



Emulate 



Agency information stored in a format u&&> by 
automated information systems. ^ 

^TJse of firmware to allow original cdde to run on 
target hardware No functional change. 



Functional User 



User of an automated information system's that 
supports an agency ^operational function (e.g., y 
personnel, finance). 3 



Operation Control 
Stream Language 



A generic term for Control Language, 
e.g. IBM's Job Control Language (JCL) 



Parallel Testing 



Parallel testirig consists of opefeting the converted 
target software in a parallel, operational mpde 
with source software to ensure that the old; and 
new systems conform functionally and that the new 
source systems run in an acceptable operational 
mode with other systems. 
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X. 



Phase 



A distinct period of time in a software conversion 
project where certain activities are performed 
The completion of all activities in the phase leads 
to the next phase, e.g. conversion planning should 
precede conversion preparation which should 
precede actual conversion. y t 



Program 
Project Manager 



Smallest amount of stand alone, executable code. 



The full-tiqie manager of a software conversion 
project 



Project Team 



Personnel appointed or assigned^to^articipate in a 
software conversion project The project team 
size and skills can change by phase, depending oa^ 
the project requirements Team members can be 
assigned from agency resources or from outsidfe 
resources (i.e. consultants, contractors). 



Recode . 



A translation of source code to ari' equivalent line 
of code on the target hardware S^h ; that the 
functional specifications remain the sam4. May be 
accomplished manually or with automated tool(s). 



Redesign 

Reprogram 
Resource Utilization 



• A change in system specifications, including 
Ad|fferent/^a]^orithms to accomplish the samfe 
/function^ code. No change to functional 

specifications. \ ^ 



A functional translation where some or all new 
code is produced utilizing new logic where 
necessary. No change to functional specifications. 

A fneasure of work units needed to pfttejs&is the 
current workload or the source system. 



Simulate 



Use of specialized code to allow original source 
•code to run on target hardware. Np change to 
functional specifications. 




Software Conversion 



The transformation, without functional change, of 
computer programs or data elements to permit 
their use jon a replacement or changed ADP 
equipment, environment, teleprocessing service or*' 
system. 



Software Conversion 
Manager 



Systeta Software 



Task 



The agency staff member who, text, to the 
conversion project manager, has the greatest 
technical interest in the status .of the software 
\5oriv6rsion project . This guide, assumes ' that the 
software conversion manager will have 'npfmal 
responsibilities for day-to-day software ope rations, 
and lack sufficient additional time to managevthe 
software conversion project. A full-time project^ 
manager will thus be assigned and work with jJie; 
ftware conversion manager during conversion! ; 



> ■ . . \. . 

A set of programs that encompass or support the 
operating system. 

/ . 

Sub-elements of work related to conversion 
activities. For example, tasks related, to 
converting Y an application system pould include 
converting the soutcfe code, dftta files or job 
stream language. \ r ' / ■ 



Test Data 



Top Management 
(Top-agency executives) 



Data that is 'used test software*; Unit test data 
^ usually' is cbnstructied %j> 'test technical aspects of 
| software and does nofcYnecesgarily Correspond to 
aqtualdata. Systems ttit data normally represents 
' operational data. Parallel test d^ta usually ^ 



is 



Translate 




operational data. 



an^ational levels of ^Jte^iment above 1 the 
u level with broad atith&Tty and oversight over 
. v or all agency operations; top management 
f authority for approving budgets and allocating 



esources. 



""A. change in language, -or version only (e.g.,. 
COBOL/68 to COBOL/74) No change in functional 
or detail specifications. (FCgC def initios). * 



Translocate 



;No change in function or detail specifications and 

change in language. (FCSC ^^inM^ 
on a^ode^ompatibldc^ 



Unit Testing: 



,The compilation, execution and ; testing of each 
target pr ogra m wife its test data. Unit test data 
technically ^fests the software arid does' not 
necessarily corregjQnjHo operational data^ C 
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